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

Commit3cbd190

Browse files
committed
Update FSM on WAL replay of page all-visible/frozen
We aren't very strict about keeping FSM up to date on WAL replay,because per-page freespace values aren't critical in replicas (can'twrite to heap in a replica; and if the replica is promoted, the valueswould be updated by VACUUM anyway). However, VACUUM since 9.6 can skipprocessing pages marked all-visible or all-frozen, and if such pages arerecorded in FSM with wrong values, those values are blindly propagatedto FSM's upper layers by VACUUM's FreeSpaceMapVacuum. (This rationaleassumes that crashes are not very frequent, because those would causeoutdated FSM to occur in the primary.)Even when the FSM is outdated in standby, things are not too badnormally, because, most per-page FSM values will be zero (other thanthose propagated with the base-backup that created the standby); onlyonce the remaining free space is less than 0.2*BLCKSZ the per-page valueis maintained by WAL replay of heap ins/upd/del. However, ifwal_log_hints=on causes complete FSM pages to be propagated to a standbyvia full-page images, many too-optimistic per-page values can end upbeing registered in the standby.Incorrect per-page values aren't critical in most cases, since aninserter that is given a page that doesn't actually contain the claimedfree space will update FSM with the correct value, and retry until itfinds a usable page. However, if there are many such updates to do, aninserter can spend a long time doing them before a usable page is found;in a heavily trafficked insert-only table with many concurrent insertersthis has been observed to cause several second stalls, causing visibleapplication malfunction.To fix this problem, it seems sufficient to have heap_xlog_visible(replay of setting all-visible and all-frozen VM bits for a heap page)update the FSM value for the page being processed. This fixes theper-page counters together with making the page skippable to vacuum, sowhen vacuum does FreeSpaceMapVacuum, the values propagated to FSM upperlayers are the correct ones, avoiding the problem.While at it, apply the same fix to heap_xlog_clean (replay of tupleremoval by HOT pruning and vacuum). This makes any space freed by thecleaning available earlier than the next vacuum in the promoted replica.Backpatch to 9.6, where this problem was diagnosed on an insert-onlytable with all-frozen pages, which were introduced as a concept in thatrelease. Theoretically it could apply with all-visible pages to olderbranches, but there's been no report of that and it doesn't backpatchcleanly anyway.Author: Álvaro Herrera <alvherre@alvh.no-ip.org>Discussion:https://postgr.es/m/20180802172857.5skoexsilnjvgruk@alvherre.pgsql
1 parentc182c1e commit3cbd190

File tree

1 file changed

+40
-12
lines changed

1 file changed

+40
-12
lines changed

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

Lines changed: 40 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -8047,15 +8047,14 @@ heap_xlog_cleanup_info(XLogReaderState *record)
80478047
}
80488048

80498049
/*
8050-
* HandlesHEAP2_CLEAN record type
8050+
* HandlesXLOG_HEAP2_CLEAN record type
80518051
*/
80528052
staticvoid
80538053
heap_xlog_clean(XLogReaderState*record)
80548054
{
80558055
XLogRecPtrlsn=record->EndRecPtr;
80568056
xl_heap_clean*xlrec= (xl_heap_clean*)XLogRecGetData(record);
80578057
Bufferbuffer;
8058-
Sizefreespace=0;
80598058
RelFileNodernode;
80608059
BlockNumberblkno;
80618060
XLogRedoActionaction;
@@ -8107,8 +8106,6 @@ heap_xlog_clean(XLogReaderState *record)
81078106
nowdead,ndead,
81088107
nowunused,nunused);
81098108

8110-
freespace=PageGetHeapFreeSpace(page);/* needed to update FSM below */
8111-
81128109
/*
81138110
* Note: we don't worry about updating the page's prunability hints.
81148111
* At worst this will cause an extra prune cycle to occur soon.
@@ -8117,18 +8114,24 @@ heap_xlog_clean(XLogReaderState *record)
81178114
PageSetLSN(page,lsn);
81188115
MarkBufferDirty(buffer);
81198116
}
8117+
81208118
if (BufferIsValid(buffer))
8119+
{
8120+
Sizefreespace=PageGetHeapFreeSpace(BufferGetPage(buffer));
8121+
81218122
UnlockReleaseBuffer(buffer);
81228123

8123-
/*
8124-
* Update the FSM as well.
8125-
*
8126-
* XXX: Don't do this if the page was restored from full page image. We
8127-
* don't bother to update the FSM in that case, it doesn't need to be
8128-
* totally accurate anyway.
8129-
*/
8130-
if (action==BLK_NEEDS_REDO)
8124+
/*
8125+
* After cleaning records from a page, it's useful to update the FSM
8126+
* about it, as it may cause the page become target for insertions
8127+
* later even if vacuum decides not to visit it (which is possible if
8128+
* gets marked all-visible.)
8129+
*
8130+
* Do this regardless of a full-page image being applied, since the
8131+
* FSM data is not in the page anyway.
8132+
*/
81318133
XLogRecordPageWithFreeSpace(rnode,blkno,freespace);
8134+
}
81328135
}
81338136

81348137
/*
@@ -8201,9 +8204,34 @@ heap_xlog_visible(XLogReaderState *record)
82018204
* wal_log_hints enabled.)
82028205
*/
82038206
}
8207+
82048208
if (BufferIsValid(buffer))
8209+
{
8210+
Sizespace=PageGetFreeSpace(BufferGetPage(buffer));
8211+
82058212
UnlockReleaseBuffer(buffer);
82068213

8214+
/*
8215+
* Since FSM is not WAL-logged and only updated heuristically, it
8216+
* easily becomes stale in standbys. If the standby is later promoted
8217+
* and runs VACUUM, it will skip updating individual free space
8218+
* figures for pages that became all-visible (or all-frozen, depending
8219+
* on the vacuum mode,) which is troublesome when FreeSpaceMapVacuum
8220+
* propagates too optimistic free space values to upper FSM layers;
8221+
* later inserters try to use such pages only to find out that they
8222+
* are unusable. This can cause long stalls when there are many such
8223+
* pages.
8224+
*
8225+
* Forestall those problems by updating FSM's idea about a page that
8226+
* is becoming all-visible or all-frozen.
8227+
*
8228+
* Do this regardless of a full-page image being applied, since the
8229+
* FSM data is not in the page anyway.
8230+
*/
8231+
if (xlrec->flags&VISIBILITYMAP_VALID_BITS)
8232+
XLogRecordPageWithFreeSpace(rnode,blkno,space);
8233+
}
8234+
82078235
/*
82088236
* Even if we skipped the heap page update due to the LSN interlock, it's
82098237
* still safe to update the visibility map. Any WAL record that clears

0 commit comments

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