diff options
| author | Robert Haas <rhaas@postgresql.org> | 2016-03-01 21:49:41 -0500 |
|---|---|---|
| committer | Robert Haas <rhaas@postgresql.org> | 2016-03-01 21:49:41 -0500 |
| commit | a892234f830e832110f63fc0a2afce2fb21d1584 (patch) | |
| tree | fbb37cd6dc4e68f450bf5360610756368c90ae46 /src/backend/storage | |
| parent | 68c521eb92c3515e3306f51a7fd3f32d16c97524 (diff) | |
| download | postgresql-a892234f830e832110f63fc0a2afce2fb21d1584.tar.gz postgresql-a892234f830e832110f63fc0a2afce2fb21d1584.zip | |
Change the format of the VM fork to add a second bit per page.
The new bit indicates whether every tuple on the page is already frozen.
It is cleared only when the all-visible bit is cleared, and it can be
set only when we vacuum a page and find that every tuple on that page is
both visible to every transaction and in no need of any future
vacuuming.
A future commit will use this new bit to optimize away full-table scans
that would otherwise be triggered by XID wraparound considerations. A
page which is merely all-visible must still be scanned in that case, but
a page which is all-frozen need not be. This commit does not attempt
that optimization, although that optimization is the goal here. It
seems better to get the basic infrastructure in place first.
Per discussion, it's very desirable for pg_upgrade to automatically
migrate existing VM forks from the old format to the new format. That,
too, will be handled in a follow-on patch.
Masahiko Sawada, reviewed by Kyotaro Horiguchi, Fujii Masao, Amit
Kapila, Simon Riggs, Andres Freund, and others, and substantially
revised by me.
Diffstat (limited to 'src/backend/storage')
| -rw-r--r-- | src/backend/storage/ipc/standby.c | 6 |
1 files changed, 4 insertions, 2 deletions
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c index 3f5df9a2e96..206fa2d69e6 100644 --- a/src/backend/storage/ipc/standby.c +++ b/src/backend/storage/ipc/standby.c @@ -270,8 +270,10 @@ ResolveRecoveryConflictWithSnapshot(TransactionId latestRemovedXid, RelFileNode * If we get passed InvalidTransactionId then we are a little surprised, * but it is theoretically possible in normal running. It also happens * when replaying already applied WAL records after a standby crash or - * restart. If latestRemovedXid is invalid then there is no conflict. That - * rule applies across all record types that suffer from this conflict. + * restart, or when replaying an XLOG_HEAP2_VISIBLE record that marks as + * frozen a page which was already all-visible. If latestRemovedXid is + * invalid then there is no conflict. That rule applies across all record + * types that suffer from this conflict. */ if (!TransactionIdIsValid(latestRemovedXid)) return; |