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