=?ISO-8859-1?Q?Christian_Schr=F6der?= <cs@xxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
