Skip site navigation (1) Skip section navigation (2)

Re: Possible PANIC in PostPrepare_Locks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Possible PANIC in PostPrepare_Locks
Date: 2013-01-14 03:27:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Heikki Linnakangas <hlinnakangas(at)vmware(dot)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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-14 03:34:33
Previous:From: Stephen FrostDate: 2013-01-14 02:16:44

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group