mirror of
https://github.com/postgres/postgres.git
synced 2025-08-15 14:02:29 +03:00
Fix lazy_scan_heap so that it won't mark pages all-frozen too soon.
Commit a892234f83
added a new bit per
page to the visibility map fork indicating whether the page is
all-frozen, but incorrectly assumed that if lazy_scan_heap chose to
freeze a tuple then that tuple would not need to later be frozen
again. This turns out to be false, because xmin and xmax (and
conceivably xvac, if dealing with tuples from very old releases) could
be frozen at separate times.
Thanks to Andres Freund for help in uncovering and tracking down this
issue.
This commit is contained in:
@@ -1054,6 +1054,8 @@ lazy_scan_heap(Relation onerel, LVRelStats *vacrelstats,
|
||||
}
|
||||
else
|
||||
{
|
||||
bool tuple_totally_frozen;
|
||||
|
||||
num_tuples += 1;
|
||||
hastup = true;
|
||||
|
||||
@@ -1062,9 +1064,11 @@ lazy_scan_heap(Relation onerel, LVRelStats *vacrelstats,
|
||||
* freezing. Note we already have exclusive buffer lock.
|
||||
*/
|
||||
if (heap_prepare_freeze_tuple(tuple.t_data, FreezeLimit,
|
||||
MultiXactCutoff, &frozen[nfrozen]))
|
||||
MultiXactCutoff, &frozen[nfrozen],
|
||||
&tuple_totally_frozen))
|
||||
frozen[nfrozen++].offset = offnum;
|
||||
else if (heap_tuple_needs_eventual_freeze(tuple.t_data))
|
||||
|
||||
if (!tuple_totally_frozen)
|
||||
all_frozen = false;
|
||||
}
|
||||
} /* scan along page */
|
||||
|
Reference in New Issue
Block a user