Magnus Hagander <magnus@hagander.net> writes:
> This looks a lot like bug #2829 (excep that one is Windows), as I
> mentioned here:
> http://archives.postgresql.org/pgsql-hackers/2007-05/msg00461.php
> Haven't looked into the actual code, though, but Tom had a suggestion in
> the original bug, but AFAIK nobody has done that yet (at least not me.:)
I reproduced this on my own machine, and basically the problem seems to
be that secure_write() has been coded to bleat on every failure. This
behavior overrides the intelligence that was put into pqcomm.c's
internal_flush() a long time ago to not report consecutive write
failures ... which worked fine at the time it was written, because it
was just calling send() not secure_write(). secure_write is obviously
inconsistent anyway, since it doesn't elog anything in the non-SSL path.
Proposed fix:
1. For cases where errno conveys all the useful info (ie,
SSL_ERROR_SYSCALL), secure_write should elog nothing and just let
its caller do it, same as the plain send() path.
2. For SSL protocol errors (SSL_ERROR_SSL), we do want to print the
error at least once. It is not clear whether repeated calls would
be likely to produce the same failure, and we don't have any cheap
way to tell whether the messages are duplicate. I'm inclined to leave
that path alone until/unless we get reports of many duplicate messages
from it.
regards, tom lane