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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Дата
Msg-id 13773.1177364074@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect  (Heikki Linnakangas <heikki@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect