Re: postgresql 9.6 - cannot freeze committed xmax

Andres Freund wrote:

> 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.

Hmm ...

After reading the 9.2 code, I don't think so. These values must
absolutely be still within the freeze limits. The version pre-pgupgrade
should have replaced the xmax with InvalidTransactionId as soon as the
tuple was freezable.

In fact, I checked 9.2's code and heap_tuple_needs_freeze tests "if xmax
not a multi and < cutoff_xid"; and in that case heap_freeze_tuple does
change the value to 0.

I hope I'm not misunderstanding what you mean.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services