"Brendan Hill" <brendanh@xxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
