Re: BUG #3266: SSL broken pipes kill the machine and fill the disk - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #3266: SSL broken pipes kill the machine and fill the disk
Date
Msg-id 16441.1179449233@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #3266: SSL broken pipes kill the machine and fill the disk  (Magnus Hagander <magnus@hagander.net>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: strange problem with ip6
Next
From: Christian Kratzer
Date:
Subject: Re: strange problem with ip6