On Tue, Apr 11, 2023 at 11:48 AM Peter Geoghegan <p...@bowt.ie> wrote: > Attached revision deals with this by spelling out the names in full > (e.g., "old_xmax" and "new_xmax"). It also reorders the output fields > to match the order from the physical UPDATE, HOT_UPDATE, and LOCK WAL > record types, on the theory that those should match the physical > record (unless there is a good reason not to, which doesn't apply > here).
I just noticed that we don't even show xmax in the case of DELETE records. Perhaps the original assumption is that it must match the record's own XID, but that's not true after the MultiXact enhancements for foreign key locking added to 9.3 (and in any case there is no reason at all to show xmax in UPDATE but not in DELETE). Attached revision v4 fixes this, making DELETE, UPDATE, HOT_UPDATE, LOCK, and LOCK_UPDATED record types consistent with each other in terms of the key names output by the heap desc routine. The field order also needed a couple of tweaks for struct consistency (and cross-record consistency) for v4. -- Peter Geoghegan
v4-0001-Fix-heapdesc-infomask-array-output.patch
Description: Binary data
