Regarding t_cid in Neon heap WAL records

Поиск
Список
Период
Сортировка
От Muhammad Malik
Тема Regarding t_cid in Neon heap WAL records
Дата
Msg-id EA2P220MB0947DC092E176F5AEA297520A6AA2@EA2P220MB0947.NAMP220.PROD.OUTLOOK.COM
обсуждение исходный текст
Ответы Re: Regarding t_cid in Neon heap WAL records
Список pgsql-hackers

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: improve performance of pg_dump with many sequences
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [18] Policy on IMMUTABLE functions and Unicode updates