Re: Hot Standy introduced problem with query cancel behavior

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 21:16:32
Message-ID: 201001072216.33783.andres@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday 07 January 2010 21:47:47 Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > The reason I suggested adding CHECK_FOR_INTERRUPTS into the recv code
> > path was that it should allow a relatively "natural" handling of
> > canceling "IDLE IN TRANSACTION" queries without doing anything in the
> > interrupt handler.
> >
> > I think it shouldn't be to hard to make that code path safe for
> > CHECK_FOR_INTERRUPTS().
>
> Idle in transaction isn't the problem (except for what it does to the
> FE/BE protocol state). The problem is what happens inside a non-idle
> transaction.
>
> Since apparently I'm still not being clear enough about this, let me
> spell it out:
> 5. According to both Simon's committed patch and his recent variant,
> ProcessInterrupts executes AbortOutOfAnyTransaction and then throws
> elog(ERROR).

> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I did not want to suggest using Simons code there. Sorry for the brevity.
should have read as "revert to old code and add two step killing (thats likely
around 10 lines or so)".

"two step killing" meaning that we signal ERROR for a few times and if nothing
happens that we like, we signal FATAL.
As the code already loops around signaling anyway that should be easy to
implement.

I have no doubt about you being right that its not practical (even more so at
this point in the release cycle) to make that AbortOutOfAnyTransaction call.

Andres

PS: Thats procarray.c: ResolveRecoveryConflictWithVirtualXIDs

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-01-07 21:17:34 Re: true serializability and predicate locking
Previous Message Robert Haas 2010-01-07 21:15:57 Re: Streaming replication and postmaster signaling