Skip site navigation (1) Skip section navigation (2)

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

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Out of memory error causes Abort, Abort tries to
Date: 2006-10-25 21:03:42
Message-ID: 1161810222.31124.70.camel@dogma.v10.wvs (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
On Wed, 2006-10-25 at 16:20 -0300, Alvaro Herrera wrote:
> Jeff Davis wrote:
> > I found the root cause of the bug I reported at:
> > 
> > http://archives.postgresql.org/pgsql-bugs/2006-10/msg00211.php
> > 
> > What happens is this:
> > * Out of memory condition causes an ERROR
> > * ERROR triggers an AbortTransaction()
> > * AbortTransaction() calls RecordTransactionAbort()
> > * RecordTransactionAbort calls smgrGetPendingDeletes()
> > * smgrGetPendingDeletes() calls palloc()
> > * palloc() fails, resulting in ERROR, causing infinite recursion
> > * elog.c detects infinite recursion, and elevates it to PANIC
> > 
> > I'm not sure how easy this is to fix, but I asked on IRC and got some
> > agreement that this is a bug.
> 
> Hmm, maybe we could have AbortTransaction switch to ErrorContext, which
> has some preallocated space, before calling RecordTransactionAbort (or
> maybe have RecordTransactionAbort itself do it).
> 
> Problem is, what happens if ErrorContext is filled up by doing this?  At
> that point we will be severely fscked up, and you probably won't get the
> PANIC either.  (Maybe it doesn't happen in this particular case, but
> seems a real risk.)
> 

If we have a way to allocate memory and recover if it fails, perhaps
RecordTransactionAbort() could set the "rels to delete" part of the log
record to some special value that means "There might be relations to
delete, but I don't know which ones". Then, if necessary, it could
determine the relations that should be deleted at recovery time.

This idea assumes that we can figure out which relations are abandoned,
and also assumes that smgrGetPendingDeletes() is the only routine that
allocates memory on the path to abort a transaction due to an out of
memory error.

Regards,
	Jeff Davis



In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-10-25 21:46:33
Subject: Re: [HACKERS] Replication documentation addition
Previous:From: Josh BerkusDate: 2006-10-25 20:59:25
Subject: Re: [HACKERS] Replication documentation addition

pgsql-bugs by date

Next:From: Tom LaneDate: 2006-10-25 22:15:25
Subject: Re: Out of memory error causes Abort, Abort tries to allocate memory
Previous:From: Alvaro HerreraDate: 2006-10-25 19:20:49
Subject: Re: Out of memory error causes Abort, Abort tries to allocate memory

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group