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

Commit255e2fb

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 parent6101bc2 commit255e2fb

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
@@ -8021,15 +8021,14 @@ heap_xlog_cleanup_info(XLogReaderState *record)
80218021
}
80228022

80238023
/*
8024-
* HandlesHEAP2_CLEAN record type
8024+
* HandlesXLOG_HEAP2_CLEAN record type
80258025
*/
80268026
staticvoid
80278027
heap_xlog_clean(XLogReaderState*record)
80288028
{
80298029
XLogRecPtrlsn=record->EndRecPtr;
80308030
xl_heap_clean*xlrec= (xl_heap_clean*)XLogRecGetData(record);
80318031
Bufferbuffer;
8032-
Sizefreespace=0;
80338032
RelFileNodernode;
80348033
BlockNumberblkno;
80358034
XLogRedoActionaction;
@@ -8081,8 +8080,6 @@ heap_xlog_clean(XLogReaderState *record)
80818080
nowdead,ndead,
80828081
nowunused,nunused);
80838082

8084-
freespace=PageGetHeapFreeSpace(page);/* needed to update FSM below */
8085-
80868083
/*
80878084
* Note: we don't worry about updating the page's prunability hints.
80888085
* At worst this will cause an extra prune cycle to occur soon.
@@ -8091,18 +8088,24 @@ heap_xlog_clean(XLogReaderState *record)
80918088
PageSetLSN(page,lsn);
80928089
MarkBufferDirty(buffer);
80938090
}
8091+
80948092
if (BufferIsValid(buffer))
8093+
{
8094+
Sizefreespace=PageGetHeapFreeSpace(BufferGetPage(buffer));
8095+
80958096
UnlockReleaseBuffer(buffer);
80968097

8097-
/*
8098-
* Update the FSM as well.
8099-
*
8100-
* XXX: Don't do this if the page was restored from full page image. We
8101-
* don't bother to update the FSM in that case, it doesn't need to be
8102-
* totally accurate anyway.
8103-
*/
8104-
if (action==BLK_NEEDS_REDO)
8098+
/*
8099+
* After cleaning records from a page, it's useful to update the FSM
8100+
* about it, as it may cause the page become target for insertions
8101+
* later even if vacuum decides not to visit it (which is possible if
8102+
* gets marked all-visible.)
8103+
*
8104+
* Do this regardless of a full-page image being applied, since the
8105+
* FSM data is not in the page anyway.
8106+
*/
81058107
XLogRecordPageWithFreeSpace(rnode,blkno,freespace);
8108+
}
81068109
}
81078110

81088111
/*
@@ -8175,9 +8178,34 @@ heap_xlog_visible(XLogReaderState *record)
81758178
* wal_log_hints enabled.)
81768179
*/
81778180
}
8181+
81788182
if (BufferIsValid(buffer))
8183+
{
8184+
Sizespace=PageGetFreeSpace(BufferGetPage(buffer));
8185+
81798186
UnlockReleaseBuffer(buffer);
81808187

8188+
/*
8189+
* Since FSM is not WAL-logged and only updated heuristically, it
8190+
* easily becomes stale in standbys. If the standby is later promoted
8191+
* and runs VACUUM, it will skip updating individual free space
8192+
* figures for pages that became all-visible (or all-frozen, depending
8193+
* on the vacuum mode,) which is troublesome when FreeSpaceMapVacuum
8194+
* propagates too optimistic free space values to upper FSM layers;
8195+
* later inserters try to use such pages only to find out that they
8196+
* are unusable. This can cause long stalls when there are many such
8197+
* pages.
8198+
*
8199+
* Forestall those problems by updating FSM's idea about a page that
8200+
* is becoming all-visible or all-frozen.
8201+
*
8202+
* Do this regardless of a full-page image being applied, since the
8203+
* FSM data is not in the page anyway.
8204+
*/
8205+
if (xlrec->flags&VISIBILITYMAP_VALID_BITS)
8206+
XLogRecordPageWithFreeSpace(rnode,blkno,space);
8207+
}
8208+
81818209
/*
81828210
* Even if we skipped the heap page update due to the LSN interlock, it's
81838211
* still safe to update the visibility map. Any WAL record that clears

0 commit comments

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