From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:32:25 |
Message-ID: | 1262885545.19367.86413.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2010-01-07 at 12:14 -0500, Tom Lane wrote:
> 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.
Hmmm. Can you check my current attempt? This may suffer this problem.
If, so can you explain a little more for me? Thanks.
--
Simon Riggs www.2ndQuadrant.com
Attachment | Content-Type | Size |
---|---|---|
another_recovery_cancel.patch | text/x-patch | 20.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2010-01-07 17:34:52 | Re: Testing with concurrent sessions |
Previous Message | Greg Sabino Mullane | 2010-01-07 17:32:03 | Re: Streaming replication and postmaster signaling |