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 | 23704.1177389440@sss.pgh.pa.us обсуждение |
| Ответ на | Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: BUG #3245: PANIC: failed to re-find shared loc k o b j
ect
Re: BUG #3245: PANIC: failed to re-find shared lock object |
| Список | pgsql-bugs |
I wrote:
> Now to start debugging.
It looks to me like the problem is that AtPrepare_Locks invokes
LockTagIsTemp, and that goes and reads various system catalogs, which
can result in new entries in the LOCALLOCK hash table, which might
result in a bucket split in same, which would result in some entries
possibly being scanned twice by the hash_seq_search scan.
Not sure about good fix, except that AtPrepare is probably a really
bad time to be doing fresh catalog searches.
Also, we have a generic issue that making fresh entries in a hashtable
might result in a concurrent hash_seq_search scan visiting existing
entries more than once; that's definitely not something any of the
existing callers are thinking about.
I'm too tired to think about fixes right now, but we've definitely
found a hotbed of actual and potential bugs.
regards, tom lane
В списке pgsql-bugs по дате отправления: