From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, Kris Jurka <books(at)ejurka(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Subject: | Re: Hot Standy introduced problem with query cancel behavior |
Date: | 2010-01-07 18:49:59 |
Message-ID: | 5521.1262890199@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:
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-01-07 18:53:41 | Re: Streaming replication and postmaster signaling |
Previous Message | Simon Riggs | 2010-01-07 18:42:06 | Re: Hot Standy introduced problem with query cancel behavior |