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 12597.1177357640@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect  (Heikki Linnakangas <heikki@enterprisedb.com>)
Ответы 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:
> Locking the same lock twice is usually handled correctly, I don't
> understand why it fails in this case. I'm thinking that the locallock
> structs somehow get out of sync with the lock structs in shared memory.
> The twophase-records are created from the locallock structs alone, so if
> there's extra entries in the locallocks table for some reason, we'd get
> the symptoms we have.

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?

> Unless you have a better idea, I'd like to add some more debug-prints to
> AtPrepare_Locks to see what gets written to the state file and why.

Seems like a reasonable thing to pursue.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

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