On Tue, Oct 17, 2017 at 3:40 AM, Alvaro Herrera wrote:
> I also realized we can stop checking (i.e. don't compare xmin to
> frozenxid) if the XMIN_FROZEN bits are set -- because in that case the
> tuple cannot possibly come from 9.3 frozen. So I think this should do
>
On Tue, Oct 17, 2017 at 12:23 PM, Peter Geoghegan wrote:
> On Tue, Oct 17, 2017 at 3:40 AM, Alvaro Herrera
> wrote:
>> Peter Geoghegan wrote:
>>
>>> Wouldn't this last "if" test, to cover the pg_upgrade case, be better
>>> targeted by comparing *raw* xmin
On Tue, Oct 17, 2017 at 3:40 AM, Alvaro Herrera wrote:
> Peter Geoghegan 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
Peter Geoghegan 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
On Fri, Oct 6, 2017 at 8:29 AM, Alvaro Herrera wrote:
> Fix traversal of half-frozen update chains
I have a question about this (this is taken from the master branch):
> bool
> HeapTupleUpdateXmaxMatchesXmin(TransactionId xmax, HeapTupleHeader htup)
> {
>