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

Commitf83d709

Browse files
committed
Merge prune, freeze and vacuum WAL record formats
The new combined WAL record is now used for pruning, freezing and 2ndpass of vacuum. This is in preparation for changing VACUUM to write acombined prune+freeze record per page, instead of separate tworecords. The new WAL record format now supports that, but the codestill always writes separate records for pruning and freezing.This reserves separate XLOG_HEAP2_* info codes for when the pruningrecord is emitted for on-access pruning or VACUUM, per PeterGeoghegan's suggestion. The record format is identical, but havingseparate info codes makes it easier analyze pruning and vacuuming withpg_waldump.The function to emit the new WAL record, log_heap_prune_and_freeze(),is in pruneheap.c. The existing heap_log_freeze_plan() and itssubroutines are moved to pruneheap.c without changes, to keep themtogether with log_heap_prune_and_freeze().Author: Melanie Plageman <melanieplageman@gmail.com>Discussion:https://www.postgresql.org/message-id/CAAKRu_azf-zH%3DDgVbquZ3tFWjMY1w5pO8m-TXJaMdri8z3933g@mail.gmail.comDiscussion:https://www.postgresql.org/message-id/CAAKRu_b2oE4GL%3Dq4g9mcByS9yT7wTQvEH9OLpabj28e%2BWKFi2A@mail.gmail.com
1 parentd44032d commitf83d709

File tree

11 files changed

+805
-600
lines changed

11 files changed

+805
-600
lines changed

‎src/backend/access/gist/gistxlog.c

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -183,10 +183,10 @@ gistRedoDeleteRecord(XLogReaderState *record)
183183
*
184184
* GiST delete records can conflict with standby queries. You might think
185185
* that vacuum records would conflict as well, but we've handled that
186-
* already.XLOG_HEAP2_PRUNE records provide the highest xid cleaned by
187-
* the vacuum of the heap and so we can resolve any conflicts just once
188-
* when that arrives. After that we know that no conflicts exist from
189-
* individual gist vacuum records on that index.
186+
* already.XLOG_HEAP2_PRUNE_VACUUM_SCAN records provide the highest xid
187+
*cleaned bythe vacuum of the heap and so we can resolve any conflicts
188+
*just oncewhen that arrives. After that we know that no conflicts
189+
*exist fromindividual gist vacuum records on that index.
190190
*/
191191
if (InHotStandby)
192192
{

‎src/backend/access/hash/hash_xlog.c

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -992,10 +992,11 @@ hash_xlog_vacuum_one_page(XLogReaderState *record)
992992
* Hash index records that are marked as LP_DEAD and being removed during
993993
* hash index tuple insertion can conflict with standby queries. You might
994994
* think that vacuum records would conflict as well, but we've handled
995-
* that already. XLOG_HEAP2_PRUNE records provide the highest xid cleaned
996-
* by the vacuum of the heap and so we can resolve any conflicts just once
997-
* when that arrives. After that we know that no conflicts exist from
998-
* individual hash index vacuum records on that index.
995+
* that already. XLOG_HEAP2_PRUNE_VACUUM_SCAN records provide the highest
996+
* xid cleaned by the vacuum of the heap and so we can resolve any
997+
* conflicts just once when that arrives. After that we know that no
998+
* conflicts exist from individual hash index vacuum records on that
999+
* index.
9991000
*/
10001001
if (InHotStandby)
10011002
{

0 commit comments

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