database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-27 07:42:10 +03:00
Code Activity

Sanitize the term "combo CID" in code comments

Browse Source 
Combo CIDs were referred in the code comments using different terms
across various places of the code, so unify a bit the term used with
what is currently in use in some of the READMEs.

Author: "Hou, Zhijie"
Discussion: https://postgr.es/m/1d42865c91404f46af4562532fdbea31@G08CNEXMBPEKD05.g08.fujitsu.local
This commit is contained in:
Michael Paquier
2021-03-25 16:08:03 +09:00
parent 438fc4a39c
commit a1999a01bb
9 changed files with 55 additions and 55 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
src/backend/replication/logical/reorderbuffer.c
View File

@@ -4736,19 +4736,19 @@ ReorderBufferToastReset(ReorderBuffer *rb, ReorderBufferTXN *txn)
* always rely on stored cmin/cmax values because of two scenarios:
*
* * A tuple got changed multiple times during a single transaction and thus
* has got a combocid. Combocid's are only valid for the duration of a
* has got a combo CID. Combo CIDs are only valid for the duration of a
* single transaction.
* * A tuple with a cmin but no cmax (and thus no combocid) got
* * A tuple with a cmin but no cmax (and thus no combo CID) got
* deleted/updated in another transaction than the one which created it
* which we are looking at right now. As only one of cmin, cmax or combocid
* which we are looking at right now. As only one of cmin, cmax or combo CID
* is actually stored in the heap we don't have access to the value we
* need anymore.
*
* To resolve those problems we have a per-transaction hash of (cmin,
* cmax) tuples keyed by (relfilenode, ctid) which contains the actual
* (cmin, cmax) values. That also takes care of combocids by simply
* (cmin, cmax) values. That also takes care of combo CIDs by simply
* not caring about them at all. As we have the real cmin/cmax values
* combocids aren't interesting.
* combo CIDs aren't interesting.
*
* As we only care about catalog tuples here the overhead of this
* hashtable should be acceptable.
@@ -4995,7 +4995,7 @@ UpdateLogicalMappings(HTAB *tuplecid_data, Oid relid, Snapshot snapshot)
/*
* Lookup cmin/cmax of a tuple, during logical decoding where we can't rely on
* combocids.
* combo CIDs.
*/
bool
ResolveCminCmaxDuringDecoding(HTAB *tuplecid_data,

4
src/backend/replication/logical/snapbuild.c
View File

@@ -42,7 +42,7 @@
* catalog in a transaction. During normal operation this is achieved by using
* CommandIds/cmin/cmax. The problem with that however is that for space
* efficiency reasons only one value of that is stored
* (cf. combocid.c). Since ComboCids are only available in memory we log
* (cf. combocid.c). Since combo CIDs are only available in memory we log
* additional information which allows us to get the original (cmin, cmax)
* pair during visibility checks. Check the reorderbuffer.c's comment above
* ResolveCminCmaxDuringDecoding() for details.
@@ -739,7 +739,7 @@ SnapBuildProcessChange(SnapBuild *builder, TransactionId xid, XLogRecPtr lsn)
}
/*
* Do CommandId/ComboCid handling after reading an xl_heap_new_cid record.
* Do CommandId/combo CID handling after reading an xl_heap_new_cid record.
* This implies that a transaction has done some form of write to system
* catalogs.
*/