Re: PG signal handler and non-reentrant malloc/free calls - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PG signal handler and non-reentrant malloc/free calls
Date
Msg-id 16906.1298992939@sss.pgh.pa.us
Whole thread Raw
In response to Re: PG signal handler and non-reentrant malloc/free calls  (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>)
Responses Re: PG signal handler and non-reentrant malloc/free calls
List pgsql-hackers
Nikhil Sontakke <nikhil.sontakke@enterprisedb.com> writes:
> On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> 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.

No, the question is why is the ImmediateInterruptOK flag set.  Whether
the interrupt actually happens isn't that relevant.  You could try
setting a watchpoint on the flag variable.

> 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 are not doing that, because that would be only a band-aid patch for
approximately 0.1% of the problems that can arise from running random
code with ImmediateInterruptOK set.  We need to find out what's leaving
that set and fix it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: error order when debug postgresql step by step?
Next
From: Ibrar Ahmed
Date:
Subject: Re: error order when debug postgresql step by step?