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

Commita0dd4c9

Browse files
committed
Improve comment on why we need ctid->(cmin,cmax) mapping.
Combocids are only part of the problem. Explain the problem in more detail.Reviewed-by: Andres FreundDiscussion:https://www.postgresql.org/message-id/1ba2899e-77f8-7866-79e5-f3b7d1251a3e@iki.fi
1 parent054ff3b commita0dd4c9

File tree

1 file changed

+9
-4
lines changed

1 file changed

+9
-4
lines changed

‎src/backend/replication/logical/snapbuild.c

Lines changed: 9 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -41,10 +41,15 @@
4141
* transactions we need Snapshots that see intermediate versions of the
4242
* catalog in a transaction. During normal operation this is achieved by using
4343
* CommandIds/cmin/cmax. The problem with that however is that for space
44-
* efficiency reasons only one value of that is stored
45-
* (cf. combocid.c). Since combo CIDs are only available in memory we log
46-
* additional information which allows us to get the original (cmin, cmax)
47-
* pair during visibility checks. Check the reorderbuffer.c's comment above
44+
* efficiency reasons, the cmin and cmax are not included in WAL records. We
45+
* cannot read the cmin/cmax from the tuple itself, either, because it is
46+
* reset on crash recovery. Even if we could, we could not decode combocids
47+
* which are only tracked in the original backend's memory. To work around
48+
* that, heapam writes an extra WAL record (XLOG_HEAP2_NEW_CID) every time a
49+
* catalog row is modified, which includes the cmin and cmax of the
50+
* tuple. During decoding, we insert the ctid->(cmin,cmax) mappings into the
51+
* reorder buffer, and use them at visibility checks instead of the cmin/cmax
52+
* on the tuple itself. Check the reorderbuffer.c's comment above
4853
* ResolveCminCmaxDuringDecoding() for details.
4954
*
5055
* To facilitate all this we need our own visibility routine, as the normal

0 commit comments

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