| 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: | Whole Thread | Raw Message | 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
| 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? |