Thread: Regarding t_cid in Neon heap WAL records
Neon added a t_cid field to heap WAL records https://github.com/yibit/neon-postgresql/blob/main/docs/core_changes.md#add-t_cid-to-heap-wal-records.
However, when replaying the delete log record, it is discarding the combo flag and storing the raw cmax on the old tuple https://github.com/neondatabase/neon/blob/main/pgxn/neon_rmgr/neon_rmgr.c#L376. This will make the tuple header different from what is in the buffer cache if the deleted tuple was using a combocid. Similarly, there was no t_cid added for the old tuple in xl_neon_heap_update, and it is using the t_cid of the new tuple to set cmax on the old tuple during redo_neon_heap_update.
Why is this not a problem when a visibility check is performed on the tuple after reading from storage, since it won't get the correct cmin value on the old tuple?
Also, what is the need of adding the t_cid of the new tuple in xl_neon_heap_update when it is already present in the xl_neon_heap_header? Seems like it is sending the same t_cid twice with the update WAL record.
Thanks,
Muhammad
On 24/07/2024 21:44, Muhammad Malik wrote: > Neon added a t_cid field to heap WAL records > https://github.com/yibit/neon-postgresql/blob/main/docs/core_changes.md#add-t_cid-to-heap-wal-records <https://github.com/yibit/neon-postgresql/blob/main/docs/core_changes.md#add-t_cid-to-heap-wal-records>. This isn't really a pgsql-hackers topic, so I've opened an issue on the neon github issue tracker for this: https://github.com/neondatabase/neon/issues/8499. (Thanks for the report though!) -- Heikki Linnakangas Neon (https://neon.tech)