Re: foreign key locks, 2nd attempt

On Thu, Feb 23, 2012 at 3:04 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
>
> Excerpts from Simon Riggs's message of jue feb 23 11:15:45 -0300 2012:
>> On Sun, Dec 4, 2011 at 12:20 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>>
>> > Making pg_multixact persistent across clean shutdowns is no bridge to cross
>> > lightly, since it means committing to an on-disk format for an indefinite
>> > period.  We should do it; the benefits of this patch justify it, and I haven't
>> > identified a way to avoid it without incurring worse problems.
>>
>> I can't actually see anything in the patch that explains why this is
>> required. (That is something we should reject more patches on, since
>> it creates a higher maintenance burden).
>>
>> Can someone explain? We might think of a way to avoid that.
>
> Sure.  The problem is that we are allowing updated rows to be locked (and
> locked rows to be updated).  This means that we need to store extended
> Xmax information in tuples that goes beyond mere locks, which is what we
> were doing previously -- they may now have locks and updates simultaneously.
>
> (In the previous code, a multixact never meant an update, it always
> signified only shared locks.  After a crash, all backends that could
> have been holding locks must necessarily be gone, so the multixact info
> is not interesting and can be treated like the tuple is simply live.)
>
> This means that this extended Xmax info needs to be able to survive, so
> that it's possible to retrieve it after a crash; because even if the
> lockers are all gone, the updater might have committed and this means
> the tuple is dead.  If we failed to keep this, the tuple would be
> considered live which would be wrong because the other version of the
> tuple, which was created by the update, is also live.

OK, thanks.

So why do we need pg_upgrade support?

If pg_multixact is not persistent now, surely there is no requirement
to have pg_upgrade do any form of upgrade? The only time we'll need to
do this is from 9.2 to 9.3, which can of course occur any time in next
year. That doesn't sound like a reason to block a patch now, because
of something that will be needed a year from now.

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