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
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
On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas
heikki.linnakan...@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
On 01.03.2011 16:40, Nikhil Sontakke wrote:
On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas
heikki.linnakan...@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
Nikhil Sontakke nikhil.sonta...@enterprisedb.com writes:
On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas
heikki.linnakan...@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,
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 your
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
On Tue, Mar 1, 2011 at 3:11 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
10 matches
Mail list logo
