BUG #2829: Runaway logs - "SSL SYSCALL error"

The following bug has been logged online:

Bug reference: 2829
Logged by: Sean
Email address: sean(dot)murphy(at)equipoint(dot)com
PostgreSQL version: 8.2
Operating system: W2K Server
Description: Runaway logs - "SSL SYSCALL error"
Details:

A couple of times in the last month or two (first on an 8.0 installation,
now again after the upgrade) I've had the server get brought down by a full
hard drive.

The pg log files are the culprit - they fill up at a rate of about 50 megs a
minute with lines reading
"SSL SYSCALL error: A blocking operation was interrupted by a call to
WSACancelBlockingCall."

I have two different VB applications used by a couple of dozen employees to
access the db using SSL server and client certs via psqlODBC (build 8.2.2.0
unicode). One of the applications connects first as a low-privilege user to
check login credentials prior to connecting again as a privileged user. I
also have several web servers that connect using the JDBC driver WITHOUT SSL
on the local subnet, and a couple of administrators who use pgAdmin on the
local subnet.

The last few entries of the log before going nova were:
SSL SYSCALL error: No error
could not receive data from client: No error
unexpected EOF on client connection

Is this a psql problem or a psqlODBC problem? Is there a way that I can
modify the server not to log this particular error, or better yet, to log it
only once? Or even to die on this error (if it's going to crash on this, it
would be nice to do it without taking the entire server down with it).

"Sean" <sean(dot)murphy(at)equipoint(dot)com> writes:
> The pg log files are the culprit - they fill up at a rate of about 50 megs a
> minute with lines reading
> "SSL SYSCALL error: A blocking operation was interrupted by a call to
> WSACancelBlockingCall."

We've seen this reported before...

> Is this a psql problem or a psqlODBC problem?

[ pokes around... ] I'm inclined to say it's an OpenSSL bug --- the
message string corresponds to WSAEINTR, which to the extent I know
anything about Windows (which is admittedly nil) seems like it should be
treated the same as EINTR on Unix, ie, retry. That is how Postgres
treats it on regular unsecured socket connections. But a look in the
OpenSSL sources finds no indication that they treat it specially,
which means they're going to think it's a hard error.

We could probably suppress the log-file-filling behavior by not
reporting duplicate messages (pqcomm.c has done that for a long
time, but there's no such logic in secure_write). But really you
want a fix for the underlying bug, and I think for that you ought
to report it to the OpenSSL folk.

regards, tom lane