On Wed, Oct 4, 2017 at 6:46 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > Wong, Yi Wen wrote: >> My interpretation of README.HOT is the check is just to ensure the chain is >> continuous; in which case the condition should be: >> >> > if (TransactionIdIsValid(priorXmax) && >> > !TransactionIdEquals(priorXmax, >> > HeapTupleHeaderGetRawXmin(htup))) >> > break; >> >> So the difference is GetRawXmin vs GetXmin, because otherwise we get the >> FreezeId instead of the Xmin when the transaction happened
As you know, on version 9.4+, as of commit 37484ad2a, we decided that we are "largely ignoring the value to which it [xmin] is set". The expectation became that raw xmin is available after freezing, but mostly for forensic purposes. I think Alvaro should now memorialize the idea that its value is actually critical in some place (htup_details.h?). > I independently arrived at the same conclusion. Since I was trying with > 9.3, the patch differs -- in the old version we must explicitely test > for the FrozenTransactionId value, instead of using GetRawXmin. Obviously you're going to have to be prepared for a raw xmin of FrozenTransactionId, even on 9.4+, due to pg_upgrade. I can see why it would be safe (or at least no more dangerous) to rely on HeapTupleHeaderGetRawXmin() in the way mentioned here, at least on installations that initdb'd on a version after commit 37484ad2a (version 9.4+). However, I'm not sure why what you propose here would be safe when even raw xmin happens to be FrozenTransactionId. Are you sure that that's truly race-free? If it's really true that we only need to check for FrozenTransactionId on 9.3, why not just do that on all versions, and never bother with HeapTupleHeaderGetRawXmin()? ("Sheer paranoia" is a valid answer; I just want us to be clear on the reasoning.) Obviously any race would have a ridiculously tiny window, but it's not obvious why this protocol would be completely race-free (in the event of a FrozenTransactionId raw xmin). -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers