> On 28 Oct 2020, at 21:21, Mark Dilger <mark.dil...@enterprisedb.com> wrote: > > The other possibillity is that this tuple is erroneously marked as > HEAP_UPDATED. heap_update() sets that, which makes sense. > rewrite_heap_tuple() copies the old tuple's bits to the new tuple and then > does some work to resolve update chains. I guess you could look at whether > that logic might leave things in an invalid state. I don't have any theory > about that.
Hi Mark and Konstantin! Recently (Oct 15, 2024) I've observed this kind of problem on one of our production clusters: an old tuple version had come to life. # select ctid,* from skipped where ctid = '(16488,13)' or ctid = '(21597,16)'; -[ RECORD 1 ]+------------------------------------- ctid | (16488,13) id | 1121skipped date_created | 2023-08-16 03:31:36.306466+03 date_updated | 2023-08-16 03:31:36.306481+03 -[ RECORD 2 ]+------------------------------------- ctid | (21597,16) id | 1121skipped date_created | 2023-08-16 03:31:36.306466+03 date_updated | 2024-09-06 14:10:47.926007+03 Freezing was failing with "cannot freeze committed xmax". xmax of old version == xmin of new one. I have no idea what is semantics of date_created and date_updated. The server was running vanilla 14 regularly updated. I suggested delete from skipped where ctid = '(16488,13)'; and it worked, monitoring issue was resolved. I found no other problems in logs, heapcheck, amcheck etc. And found no violations of id uniqueness. What was bothering me was that amcheck verify_heap() was quite about this table. Let's add some checks to detect such conditions? PFA the patch doing so. Thanks! Best regards, Andrey Borodin.
0001-Detect-hintbit-contradictions-to-commit-log.patch
Description: Binary data
