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

2011-03-01 Thread Greg Stark
On Tue, Mar 1, 2011 at 3:11 PM, Heikki Linnakangas wrote: > 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

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

2011-03-01 Thread Nikhil Sontakke
> > 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 underlyi

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

2011-03-01 Thread Andres Freund
Hi, On Tuesday, March 01, 2011 11:50:42 AM Nikhil Sontakke wrote: > >> Will try to get the call stack if needed. > > > > Yes, please. > Here is the stack trace: Thats not a stock postgres is it? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to yo

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

2011-03-01 Thread Tom Lane
Nikhil Sontakke writes: > On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas > 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 gott

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

2011-03-01 Thread Heikki Linnakangas
On 01.03.2011 16:40, Nikhil Sontakke wrote: On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas 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'r

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

2011-03-01 Thread Nikhil Sontakke
On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas 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. Ho

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

2011-03-01 Thread Heikki Linnakangas
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? -- Heikki Linnakangas E

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

2011-03-01 Thread Nikhil Sontakke
> >> Will try to get the call stack if needed. > > Yes, please. > Here is the stack trace: #0 0xe410 in __kernel_vsyscall () #1 0xb7ee676e in __lll_mutex_lock_wait () from /lib/libc.so.6 #2 0xb7e82e41 in _L_lock_4214 () from /lib/libc.so.6 #3 0xb7e80048 in free () from /lib/libc.so.6 #4

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

2011-02-28 Thread Tom Lane
Heikki Linnakangas writes: > Unless ImmediateInterruptOK is set, but it's only set around a few > blocking system calls where it is safe to do so. (Checks...) Actually, > md5_crypt_verify() looks suspicious, it does "ImmediateInterruptOK = > true", and then calls palloc() and pfree(). Hm, yeah

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

2011-02-28 Thread Heikki Linnakangas
On 28.02.2011 14:04, Nikhil Sontakke wrote: I believe we have a case where not holding off interrupts while doing a malloc() can cause a deadlock due to system or libc level locking. In this case, a pg_ctl stop in fast mode was resorted to and that caused a backend to handle the interrupt when it