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