Skip site navigation (1) Skip section navigation (2)

Re: BUG #3266: SSL broken pipes kill the machine and fill the disk

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Koczan <pjkoczan(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3266: SSL broken pipes kill the machine and fill the disk
Date: 2007-05-18 00:47:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> This looks a lot like bug #2829 (excep that one is Windows), as I
> mentioned here:
> 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

In response to

pgsql-bugs by date

Next:From: Christian KratzerDate: 2007-05-18 07:23:14
Subject: Re: strange problem with ip6
Previous:From: Bruce MomjianDate: 2007-05-18 00:09:40
Subject: Re: strange problem with ip6

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group