From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Brendan Hill" <brendanh(at)jims(dot)net> |
Cc: | "'Craig Ringer'" <craig(at)postnewspapers(dot)com(dot)au>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Idle processes chewing up CPU? |
Date: | 2009-12-30 03:47:58 |
Message-ID: | 8232.1262144878@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Brendan Hill" <brendanh(at)jims(dot)net> writes:
> I think I've confirmed the fix. Using a dirty disconnect generator, I was
> able to reliably recreate the problem within about 30-60 seconds. The
> symptoms were the same as before, however it occurred around SSL_write
> instead of SSL_read - I assume this was due to the artificial nature of the
> dirty disconnect (easier for the client to artificially break the connection
> while waiting/receiving, than sending).
> The solution you proposed solved it for SSL_write (ran for 30 minutes, no
> runaway processes), and I think it's safe to assume SSL_read too. So I
> suggest two additions:
Done, and also the same on the libpq side, since presumably it could
happen at that end as well. I suspect there is some underlying OpenSSL
bug we are masking here, but it's cheap enough that we might as well
just do it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fork | 2009-12-30 03:51:38 | Re: Planner Row Estimate with Function |
Previous Message | Nick | 2009-12-30 03:46:47 | postgresql/postgis installation |