=?ISO-8859-1?Q?Christian_Schr=F6der?= <cs@deriva.de> writes:
> any news about this issue?
Not a lot. I've been able to confirm on my own Fedora 6 machine that
the mere act of loading plperl.so into the backend causes the process
to have one thread instead of no threads, as reported by gdb. How
relevant that is isn't clear. I experimented with executing a plperl
function and then kill -9'ing the connected psql frontend process
while executing a query that returned a lot of output. But all I could
get out of that was
LOG: could not send data to client: Broken pipe
STATEMENT: select * from generate_series(1,1000000);
LOG: could not receive data from client: Connection reset by peer
LOG: unexpected EOF on client connection
The first of these lines shows that control passed unscathed through
the place where your stack trace shows it was hung up. So there is
something different between your situation and my test. It could be
that the flaky-internet-connection case is different from my
kill-the-client test, but it's pretty hard to see how that would matter
in userland, especially not for the act of calling strerror() after
control has already returned from the kernel. What I think is that the
perl stuff your session has done has included some action that changed
the condition of the backend process ... exactly what, I have no idea.
Can you show us the plperl functions that were used in these sessions?
regards, tom lane