Re: PG signal handler and non-reentrant malloc/free calls
От | Tom Lane |
---|---|
Тема | Re: PG signal handler and non-reentrant malloc/free calls |
Дата | |
Msg-id | 16906.1298992939@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PG signal handler and non-reentrant malloc/free calls (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>) |
Ответы |
Re: PG signal handler and non-reentrant malloc/free calls
|
Список | 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 по дате отправления: