Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Date
Msg-id 13773.1177364074@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-bugs
Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Tom Lane wrote:
>> Hmm.  I was just noticing this comment in PostPrepare_Locks:
>>
>> * We do this separately because we may have multiple locallock entries
>> * pointing to the same proclock, and we daren't end up with any dangling
>> * pointers.
>>
>> I'm not clear at the moment on why such a state would exist, but could
>> it be related?

> That caught my eye as well. I'm not sure what the other alternative
> would be, that might leave dangling pointers. The comment seems to be
> copy-pasted from LockReleaseAll.

I remembered what's going on there: we have a locallock entry for each
locktag + lockmode, so if you lock the same object with more than one
mode, there will be multiple locallock entries pointing to the same lock
(and proclock).  The comment is worrying about what'd happen if we
deleted shared and local entries in parallel and then errored out
partway through that.

It doesn't appear possible for there to be multiple locallock entries
for the same locktag + lockmode, unless the hashtable code is completely
broken, and I imagine we'd have noticed that before now.  I also spent
some time wondering if the 2PC code could mistakenly execute the same
2PC record twice, but that didn't look plausible either.  Tis confusing.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Next
From: Tom Lane
Date:
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect