Re: postgresql 9.6 - cannot freeze committed xmax

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@alvh.no-ip.org>
> 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