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!  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Re: Error during hash index scans can cause postgres halt!  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #4019: Comparison of user defined domain doesn't work
Следующее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: Error during hash index scans can cause postgres halt!