On 01.03.2011 16:40, Nikhil Sontakke wrote:
> On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas
> <heikki.linnakangas@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
