diff options
| author | Michael Paquier <michael@paquier.xyz> | 2021-03-25 16:08:03 +0900 |
|---|---|---|
| committer | Michael Paquier <michael@paquier.xyz> | 2021-03-25 16:08:03 +0900 |
| commit | a1999a01bb56c5f5451116abe61b892b2eec5e49 (patch) | |
| tree | 1df99c815f9d6f7057748b841bf4297d6f6a5329 /src/backend/replication/logical/reorderbuffer.c | |
| parent | 438fc4a39c3905b7af88bb848bc5aeb1308a017d (diff) | |
Sanitize the term "combo CID" in code comments
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
Diffstat (limited to 'src/backend/replication/logical/reorderbuffer.c')
| -rw-r--r-- | src/backend/replication/logical/reorderbuffer.c | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c index c291b05a423..127f2c4b168 100644 --- a/src/backend/replication/logical/reorderbuffer.c +++ b/src/backend/replication/logical/reorderbuffer.c @@ -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, |