Re: Hot Standy introduced problem with query cancel behavior - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hot Standy introduced problem with query cancel behavior
Date
Msg-id 5521.1262890199@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hot Standy introduced problem with query cancel behavior  (Andres Freund <andres@anarazel.de>)
Responses Re: Hot Standy introduced problem with query cancel behavior
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Stupid question:

> Why dont we add CHECK_FOR_INTERRUPTS (or something similar) to everything 
> calling recv (especially in the EINTR) case? 

We pretty much have CHECK_FOR_INTERRUPTS everywhere that it's safe
already.  The problem here is not a lack of execution of
CHECK_FOR_INTERRUPTS, but what to do inside it.  Although I pointed to
an interrupt service routine as being the worst case, the fact is that
Simon's code will crash the system in a large number of scenarios even
when ProcessInterrupts is called from CHECK_FOR_INTERRUPTS rather than
directly from the signal handler.  You can't just abort transactions and
then return to a nest of functions that think they still have a live
transaction they can resume.  This is why the standard error code path
has the AbortTransaction call out in the sigjmp catcher, not inside
elog() itself.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: true serializability and predicate locking
Next
From: Bruce Momjian
Date:
Subject: Re: Streaming replication and postmaster signaling