Re: Hot Standy introduced problem with query cancel behavior

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Joachim Wieland <joe(at)mcknight(dot)de>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, 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 17:14:48
Message-ID: 27233.1262884488@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote:
>> @Simon: Is there a reason why you have not yet removed recoveryConflictMode
>> from PGPROC?

> Unfortunately we still need a mechanism to mark which backends have been
> cancelled already. Transaction state for virtual transactions isn't
> visible on the procarray, so we need something there to indicate that a
> backend has been sent a conflict. Otherwise we'd end up waiting for it
> endlessly. The name will be changing though.

While we're discussing this: the current coding with
AbortOutOfAnyTransaction within ProcessInterrupts is *utterly* unsafe.
I realize that's just a toy placeholder, but getting rid of it has to be
on the list of stop-ship items. Right at the moment I'd prefer to see
CONFLICT_MODE_ERROR always turned into CONFLICT_MODE_FATAL than to
imagine this is going to work.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2010-01-07 17:15:14 Re: Streaming replication and postmaster signaling
Previous Message David E. Wheeler 2010-01-07 17:10:59 Re: Testing with concurrent sessions