Re: Some 9.5beta2 backend processes not terminating properly?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Shay Rojansky <roji(at)roji(dot)org>, hlinnaka(at)iki(dot)fi, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Some 9.5beta2 backend processes not terminating properly?
Date: 2015-12-30 19:13:09
Message-ID: 22034.1451502789@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2015-12-30 13:26:34 -0500, Tom Lane wrote:
>> I doubt that is what is happening here, because those errnos don't
>> seem sensible for an EOF condition, but I'd still feel more comfortable
>> if be_tls_read/be_tls_write handled SSL_ERROR_SYSCALL like this:
>> ...

> Being a bit more defensive here sounds sensible. But I think it might be
> better to only set WL_SOCKET_READABLE/WL_SOCKET_WRITEABLE in
> be_tls_read/be_tls_write correspondingly. It's possible that we'd
> otherwise just end up in an endless loop.

Mumble. We don't have enough visibility into SSL's internal protocol
to know whether it's currently trying to read the socket or write it,
unless it tells us. I think if we wait for only readable or only
writable based on what the high-level request is, we risk getting stuck.

(In practice, if the syscall error is persistent, we're likely to fail
pretty soon anyway. But if it were some transient error, we'd be
more likely to successfully recover if we wait for either condition.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-12-30 19:17:05 Re: Fwd: Avoid endless futile table locks in vacuuming.
Previous Message Andres Freund 2015-12-30 18:58:16 Re: Some 9.5beta2 backend processes not terminating properly?