On 29 August 2014 01:04, Thomas Munro mu...@ip9.org wrote:
On 28 August 2014 23:45, Tom Lane t...@sss.pgh.pa.us wrote:
I don't claim to be an expert on this stuff, but I had the idea that
multithreaded environments were supposed to track signal state per-thread
not just per-process, precisely
Hello,
A while back someone showed me a program blocking in libpq 9.2 on
Solaris 11, inside sigwait called by pq_reset_sigpipe. It had
happened a couple of times before during a period of
instability/crashing with a particular DB (a commercial PostgreSQL
derivative, but the client was using
Thomas Munro mu...@ip9.org writes:
My theory is that if two connections accessed by different threads get
shut down around the same time, there is a race scenario where each of
them fails to write to its socket, sees errno == EPIPE and then sees a
pending SIGPIPE with sigpending(), but only
On 28 August 2014 23:45, Tom Lane t...@sss.pgh.pa.us wrote:
I don't claim to be an expert on this stuff, but I had the idea that
multithreaded environments were supposed to track signal state per-thread
not just per-process, precisely because of issues like this.
After some googling, I found
