"Brendan Hill" <brendanh@jims.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