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
|
| Список | 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 по дате отправления: