Re: cannot freeze committed xmax

> On 28 Oct 2020, at 21:21, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)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.