Re: Out of memory error causes Abort, Abort tries to

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Out of memory error causes Abort, Abort tries to
Дата
Msg-id 1161880511.31124.100.camel@dogma.v10.wvs
обсуждение исходный текст
Ответ на Re: Out of memory error causes Abort, Abort tries to allocate memory  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Wed, 2006-10-25 at 18:15 -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Jeff Davis wrote:
> >> * smgrGetPendingDeletes() calls palloc()
> >> * palloc() fails, resulting in ERROR, causing infinite recursion
>
> > Hmm, maybe we could have AbortTransaction switch to ErrorContext, which
> > has some preallocated space, before calling RecordTransactionAbort (or
> > maybe have RecordTransactionAbort itself do it).
>
> Seems like it'd be smarter to try to free some memory before we push
> forward with transaction abort.  ErrorContext has only a limited amount
> of space ...
>

In the particular case I'm referring to, it's the referential integrity
constraints using all the memory. Is that memory allocated in a
convenient context to free before the abort?

Glancing at the code, I think that it would work to MemoryContextReset()
the query's memory context, because the pending deletes (of the
relnodes) are allocated in TopMemoryContext. After the query's memory
context is reset, there should be plenty of space to finish the abort
within that context.

Is there any data in the query's memory context that needs to be saved
after we know we're aborting?

Regards,
    Jeff Davis

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "Simon"
Дата:
Сообщение: BUG #2723: Provider / driver connection for VB.NET
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #2721: configuration issue