On Thu, Oct 12, 2017 at 7:31 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: >> Wouldn't this last "if" test, to cover the pg_upgrade case, be better >> targeted by comparing *raw* xmin to FrozenTransactionId? You're using >> the potentially distinct xmin value returned by >> HeapTupleHeaderGetXmin() for the test here. I think we should be >> directly targeting tuples frozen on or before 9.4 (prior to >> pg_upgrade) instead. > > Yes, agreed, I should change that. Thanks for continuing to think about > this.
I haven't really followed this thread in depth, but I'm very nervous about the idea that we should ever be examining the raw-xmin of a tuple that has been marked HEAP_XMIN_FROZEN for anything other than forensic purposes. The design principle I followed in writing the original patch was that marking a tuple HEAP_XMIN_FROZEN was identical to setting the xmin to 2 except that the original xmin was still available for manual inspection. If we're finding that we need the raw xmin after freezing, doesn't that mean that our freezing algorithm was flat busted prior to that commit? And maybe still busted when things wrap around multiple times and raw-xmins are reused? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers