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
