Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group