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