Re: Hot Standy introduced problem with query cancel behavior

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

In response to

Responses

Browse pgsql-hackers by date

  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