From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Ah-hah, I see the problem: EndPortalAllocMode() |
Date: | 1999-08-13 22:17:53 |
Message-ID: | 6303.934582673@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I discovered that I could reproduce the coredump Oliver and Tony were
talking about by the simple expedient of removing pg_vlock manually
while vacuum is running. Armed with a debugger it didn't take long to
find out what's going wrong:
(a) vacuum.c does a CommitTransaction to commit its final table's
worth of fixes.
(b) CommitTransaction calls EndPortalAllocMode.
(c) vacuum calls vc_shutdown, which tries to remove pg_vlock,
and reports an error when the unlink() call fails.
(d) during error cleanup, AbortTransaction is called.
(e) AbortTransaction calls EndPortalAllocMode. There has been no
intervening StartPortalAllocMode, so the portal's context stack
is empty. EndPortalAllocMode tries to free a nonexistent memory
context (or, if you have asserts turned on, dies with an assert
failure). Ka-boom.
It seems to me that EndPortalAllocMode ought to be a little more
forgiving of being called when the portal's context stack is empty.
Otherwise, it is unsafe to call elog() from anywhere except within
a transaction, because any attempt to abort a non-existent transaction
*will* coredump in this code.
However, I'd like confirmation from someone who knows portalmem.c
a little better that this is a good change to make. Is there a
better way?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 1999-08-13 23:30:34 | How to get 'psql -q' runs really quiet ? |
Previous Message | Tom Lane | 1999-08-13 21:31:47 | Re: [HACKERS] Aborted Transaction During Vacuum |