|
41 | 41 | * transactions we need Snapshots that see intermediate versions of the |
42 | 42 | * catalog in a transaction. During normal operation this is achieved by using |
43 | 43 | * 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 |
48 | 53 | * ResolveCminCmaxDuringDecoding() for details. |
49 | 54 | * |
50 | 55 | * To facilitate all this we need our own visibility routine, as the normal |
|