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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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.
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+.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-10-25 19:20:49 | Re: Out of memory error causes Abort, Abort tries to allocate memory |
Previous Message | Thomas H. | 2006-10-25 18:22:00 | Re: 8.2beta1 (w32): server process crash (tsvector) |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2006-10-25 18:59:28 | Re: [HACKERS] Replication documentation addition |
Previous Message | Bruce Momjian | 2006-10-25 18:41:02 | Re: [HACKERS] Replication documentation addition |