Ah-hah, I see the problem: EndPortalAllocMode()

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

Browse pgsql-hackers by date

  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