On Thu, Oct 12, 2017 at 7:31 PM, Alvaro Herrera <alvherre@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