Regarding t_cid in Neon heap WAL records

From: Muhammad Malik <muhammad(dot)malik1(at)hotmail(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Regarding t_cid in Neon heap WAL records
Date: 2024-07-24 18:44:04
Message-ID: EA2P220MB0947DC092E176F5AEA297520A6AA2@EA2P220MB0947.NAMP220.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-07-24 18:47:06 Re: [18] Policy on IMMUTABLE functions and Unicode updates
Previous Message Nathan Bossart 2024-07-24 18:36:34 Re: improve performance of pg_dump with many sequences