Heikki Linnakangas <hlinnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
