On 29 August 2014 01:04, Thomas Munro wrote:
> On 28 August 2014 23:45, Tom Lane 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 th
On 28 August 2014 23:45, Tom Lane 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 reply #3 in
https
Thomas Munro 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 one thread r
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 regul
