Re: Possible PANIC in PostPrepare_Locks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Possible PANIC in PostPrepare_Locks
Date
Msg-id 25017.1358134032@sss.pgh.pa.us
Whole thread Raw
In response to Re: Possible PANIC in PostPrepare_Locks  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> On 11.01.2013 04:16, Tom Lane wrote:
>> Also, it looks like we'll need two code paths in PostPrepare_Locks to
>> deal with the possibility that a conflicting entry already exists?
>> I'm not sure this is possible, but I'm not sure it's not, either.

> If I understand this correctly, that would mean that someone else is 
> holding a lock that conflicts with the lock the 
> transaction-being-prepared holds. That shouldn't happen.

After looking at it again I decided the case was impossible because
there can be at most one PROCLOCK for any given lock among those held
by our own PGPROC (else there's already duplicate keys in the proclock
table); so we will create at most one PROCLOCK per lock for the new
dummy PGPROC.  Any collision would imply that the new PGPROC already
held some of those locks, which it surely should not.

So I've committed a patch in which the occurrence of any such collision
will result in a PANIC, but out-of-memory failures are not possible.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: [PATCH] COPY .. COMPRESSED
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] COPY .. COMPRESSED