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

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Out of memory error causes Abort, Abort tries to
Date: 2006-10-26 16:35:11
Message-ID: 1161880511.31124.100.camel@dogma.v10.wvs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Wed, 2006-10-25 at 18:15 -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2006-10-26 17:02:37 Re: BUG #2721: configuration issue
Previous Message Simon 2006-10-26 06:11:36 BUG #2723: Provider / driver connection for VB.NET

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-10-26 16:59:14 Re: Nasty btree deletion bug
Previous Message Tom Lane 2006-10-26 16:31:50 Re: Nasty btree deletion bug