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

Out of memory error causes Abort, Abort tries to allocate memory

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Out of memory error causes Abort, Abort tries to allocate memory
Date: 2006-10-25 18:54:38
Message-ID: 1161802478.31124.43.camel@dogma.v10.wvs (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
I found the root cause of the bug I reported at:

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.

It seems to me, in order to fix it, we would have to avoid allocating
memory on the AbortTransaction path. All smgrGetPendingDeletes() needs
to allocate is a few dozen bytes (depending on the number of relations
to be deleted). Perhaps it could allocate those bytes as list of pending
deletes fills up. Or maybe we can somehow avoid needing to record the
relnodes to be deleted in order for the abort to succeed.

I'm still not sure why foreign keys on large insert statements don't eat
memory on 7.4, but do on 8.0+.

	Jeff Davis


pgsql-hackers by date

Next:From: Josh BerkusDate: 2006-10-25 18:59:28
Subject: Re: [HACKERS] Replication documentation addition
Previous:From: Bruce MomjianDate: 2006-10-25 18:41:02
Subject: Re: [HACKERS] Replication documentation addition

pgsql-bugs by date

Next:From: Alvaro HerreraDate: 2006-10-25 19:20:49
Subject: Re: Out of memory error causes Abort, Abort tries to allocate memory
Previous:From: Thomas H.Date: 2006-10-25 18:22:00
Subject: Re: 8.2beta1 (w32): server process crash (tsvector)

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