On 01.03.2011 16:40, Nikhil Sontakke wrote:
On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
On 01.03.2011 12:50, Nikhil Sontakke wrote:
Will try to get the call stack if needed.
Yes, please.
Here is the stack trace:
Hmm, it looks like ImmediateInterruptOK is set, while we're busy running a
query. How come? Can you debug that? Where does it get set?
Ah, this is not exactly an easily reproducible problem :( You gotta be
lucky enough to be able to interrupt inside a malloc call.
You could put a sleep() just before the malloc(). Even if you can't
reproduce a crash, we know that we shouldn't be calling malloc() in any
codepath where ImmediateInterruptOK == true.
Heck, you can just put an Assert(!ImmediateInterruptOK) there, although
it will fire in the authentication phase because of the issue with
ClientAuthentication. You can set debug_assertions=off in
postgresql.conf and enable it again with SET after logging in to get
around that.
But adding hold/resume interrrupts in mcxt.c (not aset.c, since we
want to be agnostic to the underlying layer) should be good enough to
handle this non-re-entrant issue, no?
We shouldn't be running with ImmediateInterruptOK == true to begin with.
There are many other things beside malloc/free that are not safe to be
interrupted like that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
