Re: Escaping from blocked send() reprised.

On 2014-09-26 21:02:16 +0300, Heikki Linnakangas wrote:
> I propose the attached patch. It adds a new flag ImmediateDieOK, which is a
> weaker form of ImmediateInterruptOK that only allows handling a pending
> die-signal in the signal handler.
>
> Robert, others, do you see a problem with this?

Per se I don't have a problem with it. There does exist the problem that
the user doesn't get a error message in more cases though. On the other
hand it's bad if any user can prevent the database from restarting.

> Over IM, Robert pointed out that it's not safe to jump out of a signal
> handler with siglongjmp, when we're inside library calls, like in a callback
> called by OpenSSL. But even with current master branch, that's exactly what
> we do. In secure_raw_read(), we set ImmediateInterruptOK = true, which means
> that any incoming signal will be handled directly in the signal handler,
> which can mean elog(ERROR). Should we be worried? OpenSSL might get confused
> if control never returns to the SSL_read() or SSL_write() function that
> called secure_raw_read().

But this is imo prohibitive. Yes, we're doing it for a long while. But
no, that's not ok. It actually prompoted me into prototyping the latch
thing (in some other thread). I don't think existing practice justifies
expanding it further.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services