Re: pgsql: Fix a couple of bugs in MultiXactId freezing - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pgsql: Fix a couple of bugs in MultiXactId freezing
Date
Msg-id 20131214120533.GA25520@awork2.anarazel.de
Whole thread Raw
In response to Re: pgsql: Fix a couple of bugs in MultiXactId freezing  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 2013-12-13 17:08:46 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > Afaics this will cause HEAP_KEYS_UPDATED to be reset, is that
> > problematic? I don't really remember what it's needed for TBH...
> 
> So we do reset HEAP_KEYS_UPDATED, and in general that bit seems critical
> for several things.  So it should be kept when a Xmax is carried over
> from the pre-frozen version of the tuple.  But while reading through
> that, I realize that we should also be keeping HEAP_HOT_UPDATED in that
> case.  And particularly we should never clear HEAP_ONLY_TUPLE.

That's only for the multi->plain xid case tho, right?

> So I think heap_execute_freeze_tuple() is wrong, because it's resetting
> the whole infomask to zero, and then setting it to only the bits that
> heap_prepare_freeze_tuple decided that it needed set.  That seems bogus
> to me.  heap_execute_freeze_tuple() should only clear a certain number
> of bits, and then possibly set some of the same bits; but the remaining
> flags should remain untouched.

Uh, my version and the latest you've sent intiially copy the original
infomask to the freeze plan and then manipulate those. That seems fine
to me. Am I missing something?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: PoC: Partial sort
Next
From: Andres Freund
Date:
Subject: Re: "stuck spinlock"