Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitb37a083

Browse files
Refine the definition of page-level freezing.
Improve comments added by commit1de58df which describe thelazy_scan_prune "freeze the page" path. These newly revised commentsare based on suggestions from Jeff Davis.In passing, remove nearby visibility_cutoff_xid comments left over fromcommit6daeeb1.Author: Peter Geoghegan <pg@bowt.ie>Reviewed-By: Jeff Davis <pgsql@j-davis.com>Discussion:https://postgr.es/m/ebc857107fe3edd422ef8a65191ca4a8da568b9b.camel@j-davis.com
1 parentbf03cfd commitb37a083

File tree

2 files changed

+15
-28
lines changed

2 files changed

+15
-28
lines changed

‎src/backend/access/heap/vacuumlazy.c

Lines changed: 7 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1788,13 +1788,13 @@ lazy_scan_prune(LVRelState *vacrel,
17881788
if (tuples_frozen==0)
17891789
{
17901790
/*
1791-
* We're freezing all eligible tuples on the page, but have no
1792-
*freeze plans to execute.This is structured as a case where
1793-
*the pageisnominally frozen so that we set pages all-frozen
1794-
*whenever no freeze plans need to be executed to make it safe.
1795-
*If this was handled via "no freeze" processing instead then
1796-
*VACUUM would senselessly waste certain opportunities to set
1797-
*pages all-frozen (not just all-visible) at no added cost.
1791+
* We have no freeze plans to execute, so there's no added cost
1792+
*from following the freeze path.That's why it was chosen.
1793+
*Thisisimportant in the case where the page only contains
1794+
*totally frozen tuples at this point (perhaps only following
1795+
*pruning). Such pages can be marked all-frozen in the VM by our
1796+
*caller, even though none of its tuples were newly frozen here
1797+
*(note that the "no freeze" path never sets pages all-frozen).
17981798
*
17991799
* We never increment the frozen_pages instrumentation counter
18001800
* here, since it only counts pages with newly frozen tuples
@@ -1859,12 +1859,6 @@ lazy_scan_prune(LVRelState *vacrel,
18591859
if (!heap_page_is_all_visible(vacrel,buf,&cutoff,&all_frozen))
18601860
Assert(false);
18611861

1862-
/*
1863-
* It's possible that we froze tuples and made the page's XID cutoff
1864-
* (for recovery conflict purposes) FrozenTransactionId. This is okay
1865-
* because visibility_cutoff_xid will be logged by our caller in a
1866-
* moment.
1867-
*/
18681862
Assert(!TransactionIdIsValid(cutoff)||
18691863
cutoff==prunestate->visibility_cutoff_xid);
18701864
}

‎src/include/access/heapam.h

Lines changed: 8 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -145,16 +145,14 @@ typedef struct HeapPageFreeze
145145
/*
146146
* "Freeze" NewRelfrozenXid/NewRelminMxid trackers.
147147
*
148-
* Trackers used when heap_freeze_execute_prepared freezes the page, and
149-
* when page is "nominally frozen", which happens with pages where every
150-
* call to heap_prepare_freeze_tuple produced no usable freeze plan.
151-
*
152-
* "Nominal freezing" enables vacuumlazy.c's approach of setting a page
153-
* all-frozen in the visibility map when every tuple's 'totally_frozen'
154-
* result is true. That always works in the same way, independent of the
155-
* need to freeze tuples, and without complicating the general rule around
156-
* 'totally_frozen' results (which is that 'totally_frozen' results are
157-
* only to be trusted with a page that goes on to be frozen by caller).
148+
* Trackers used when heap_freeze_execute_prepared freezes, or when there
149+
* are zero freeze plans for a page. It is always valid for vacuumlazy.c
150+
* to freeze any page, by definition. This even includes pages that have
151+
* no tuples with storage to consider in the first place. That way the
152+
* 'totally_frozen' results from heap_prepare_freeze_tuple can always be
153+
* used in the same way, even when no freeze plans need to be executed to
154+
* "freeze the page". Only the "freeze" path needs to consider the need
155+
* to set pages all-frozen in the visibility map under this scheme.
158156
*
159157
* When we freeze a page, we generally freeze all XIDs < OldestXmin, only
160158
* leaving behind XIDs that are ineligible for freezing, if any. And so
@@ -178,11 +176,6 @@ typedef struct HeapPageFreeze
178176
* VACUUM scans a page that isn't cleanup locked. Both code paths are
179177
* based on the same general idea (do less work for this page during the
180178
* ongoing VACUUM, at the cost of having to accept older final values).
181-
*
182-
* When vacuumlazy.c caller decides to do "no freeze" processing, it must
183-
* not go on to set the page all-frozen (setting the page all-visible
184-
* could still be okay). heap_prepare_freeze_tuple's 'totally_frozen'
185-
* results can only be used on a page that also gets frozen as instructed.
186179
*/
187180
TransactionIdNoFreezePageRelfrozenXid;
188181
MultiXactIdNoFreezePageRelminMxid;

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp