Re: Error during hash index scans can cause postgres halt!
От | Tom Lane |
---|---|
Тема | Re: Error during hash index scans can cause postgres halt! |
Дата | |
Msg-id | 12594.1204899189@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Error during hash index scans can cause postgres halt! ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
Ответы |
Re: Error during hash index scans can cause postgres halt!
Re: Error during hash index scans can cause postgres halt! |
Список | pgsql-bugs |
"Heikki Linnakangas" <heikki@enterprisedb.com> writes: > I can reproduce this, with --enable-cassert. It crashes when aborting > the transaction, in ReleaseResources_hash. The HashScanList items are > allocated in ExecutorState memory context, but that context has already > been deleted by the time we get to ReleaseResources_hash. Ouch. So this has been broken (by me, I think :-() since 8.0. Tells you something about how many people use hash indexes :-( > Another idea would be to allocate the HashScanList items in a > longer-lived memory context. The IndexScanDesc struct pointed to by the > HashScanList would still be in ExecutorState context, but that's all > right because we don't need to access it in ReleaseResources_hash. That seems like a winner to me. We can rely on the resource owner mechanism to free up individual HashScanList items, so there's no real need to keep them in a short-lived context. I'm inclined to just drop them into TopMemoryContext. We could make a hash-specific context but I'm not convinced it's worth the extra code to do it. regards, tom lane
В списке pgsql-bugs по дате отправления: