Re: BUG #3266: SSL broken pipes kill the machine and fill the disk
От | Tom Lane |
---|---|
Тема | Re: BUG #3266: SSL broken pipes kill the machine and fill the disk |
Дата | |
Msg-id | 16441.1179449233@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #3266: SSL broken pipes kill the machine and fill the disk (Magnus Hagander <magnus@hagander.net>) |
Список | 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 по дате отправления: