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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
