Hi, On 2018-02-28 20:30:19 -0300, Alvaro Herrera wrote: > From 4ecaa6cdc041d9f44d54f9d56588ea73c1c6f3c7 Mon Sep 17 00:00:00 2001 > From: Alvaro Herrera <alvherre@xxxxxxxxxxxxxx> > Date: Wed, 28 Feb 2018 20:16:35 -0300 > Subject: [PATCH] Fix freeze xmax bug > > --- > src/backend/access/heap/heapam.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c > index 8a846e7dba..dc762f913d 100644 > --- a/src/backend/access/heap/heapam.c > +++ b/src/backend/access/heap/heapam.c > @@ -6799,7 +6799,7 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple, > * independent of committedness, since a committed lock holder has > * released the lock). > */ > - if (!(tuple->t_infomask & HEAP_XMAX_LOCK_ONLY) && > + if (!HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask) > && Good catch. Wonder if this a big enough fix? Isn't the bug "one layer up"? We shouldn't do the TransactionIdPrecedes() calls in the surrounding block, in the first place, right? Right now we could very well hit both ERROR: found xmax %u from before relfrozenxid %u and ERROR: cannot freeze committed xmax %u and freeze_xmax, totally_frozen will be wrong. I think that's largely harmless, but we should fix it nonetheless, and inspect other relevant sites. Greetings, Andres Freund
