Re: PG signal handler and non-reentrant malloc/free calls

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PG signal handler and non-reentrant malloc/free calls
Date: 2011-03-01 15:22:19
Message-ID: 16906.1298992939@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com> writes:
> On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ibrar Ahmed 2011-03-01 15:27:50 Re: error order when debug postgresql step by step?
Previous Message Kevin Grittner 2011-03-01 15:21:15 Re: error order when debug postgresql step by step?