pgsql: Add HOLD/RESUME_INTERRUPTS in HandleCatchupInterrupt/HandleNotif - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Add HOLD/RESUME_INTERRUPTS in HandleCatchupInterrupt/HandleNotif
Date
Msg-id E1VrY3v-00020v-5L@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Add HOLD/RESUME_INTERRUPTS in HandleCatchupInterrupt/HandleNotifyInterrupt.

This prevents a possible longjmp out of the signal handler if a timeout
or SIGINT occurs while something within the handler has transiently set
ImmediateInterruptOK.  For safety we must hold off the timeout or cancel
error until we're back in mainline, or at least till we reach the end of
the signal handler when ImmediateInterruptOK was true at entry.  This
syncs these functions with the logic now present in handle_sig_alarm.

AFAICT there is no live bug here in 9.0 and up, because I don't think we
currently can wait for any heavyweight lock inside these functions, and
there is no other code (except read-from-client) that will turn on
ImmediateInterruptOK.  However, that was not true pre-9.0: in older
branches ProcessIncomingNotify might block trying to lock pg_listener, and
then a SIGINT could lead to undesirable control flow.  It might be all
right anyway given the relatively narrow code ranges in which NOTIFY
interrupts are enabled, but for safety's sake I'm back-patching this.

Branch
------
REL9_0_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/0a63f7d977777fc934589bdd7229929ab0325d55

Modified Files
--------------
src/backend/commands/async.c     |   14 ++++++++++----
src/backend/storage/ipc/sinval.c |   14 ++++++++++----
2 files changed, 20 insertions(+), 8 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Add HOLD/RESUME_INTERRUPTS in HandleCatchupInterrupt/HandleNotif
Next
From: Alvaro Herrera
Date:
Subject: pgsql: Rework MultiXactId cache code