Mark Kirkwood <mark.kirkw...@catalyst.net.nz> writes:
> If I have done this right, then this is the trace for the 1st message...
> from my wandering through the calls here it looks like a normal commit,
> and something goes a bit weird as SI messages are being processed...
Seems like the critical bit is here:
> #11 0x00007f4e2a53d985 in exit () from /lib/x86_64-linux-gnu/libc.so.6
> #12 0x00007f4e272b951a in ?? () from /usr/lib/libR.so
> #13 <signal handler called>
> #14 0x00007f4e2a538707 in kill () from /lib/x86_64-linux-gnu/libc.so.6
> #15 0x00000000006152e5 in SICleanupQueue (
> callerHasWriteLock=callerHasWriteLock@entry=1 '\001',
> minFree=minFree@entry=4) at sinvaladt.c:672
Frame 15 is definitely SICleanupQueue trying to send a catchup SIGUSR1
interrupt to the furthest-behind backend. The fact that we go directly
into a signal handler from the kill() suggests that the furthest-behind
backend is actually *this* backend, which perhaps is a bit surprising,
but it's supposed to work. What it looks like, though, is that libR has
commandeered the SIGUSR1 signal handler, and just to be extra special
unfriendly to the surrounding program, it does an exit() when it traps a
SIGUSR1.
Unless libR can be coerced into not screwing up our signal handlers,
I'd say that PL/R is broken beyond repair. That would be unfortunate.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
