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

Re: idle in txn query cancellation

From: Andres Freund <andres(at)anarazel(dot)de>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: idle in txn query cancellation
Date: 2010-02-15 10:38:06
Message-ID: 201002151138.08407.andres@anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On Monday 15 February 2010 09:50:08 Simon Riggs wrote:
> On Sat, 2010-02-13 at 22:37 +0100, Andres Freund wrote:
> > The first patch adds the capability to add a flag to ereport like:
> > ereport(ERROR | LOG_NO_CLIENT)
> > Tom earlier suggested using COMERROR but thats just a version of LOG
> > which doesnt report to the client. The patch makes that to be a
> > synonym of LOG | LOG_NO_CLIENT.
> > While its not the most pretty API I dont think its that bad because
> > the directionality is somewhat a property of the loglevel. Beside it
> > would generate a lot of useless noise and breakage.
> > 
> > The second patch changes the FATAL during cancelling an idle in txn
> > query into  ERROR | LOG_NO_CLIENT.
> > To avoid breaking the known state there also may no "ready for query"
> > message get sent. The patch ensures that by setting and checking a
> > "silent_error_while_idle" variable.
> > 
> > That way the client will not see that an error occured until the next
> > command sent but I dont think there is a solution to that in 9.0
> > timeframe if at all.
> > 
> > The patch only adds that for the recovery conflict path for now.
> > 
> > What do you think? Is it worth applying something like that now? If
> > yes I would try to test the patch some more (obviously the patch
> > survives the regression tests, but they do not seem to check the
> > extended query protocol at all).
> 
> I think that is much better than FATAL. If it works I think we should
> apply it for this release.
It does work for me at least ;-). I only have marginal testing with the 
extended query protocol though and I think the error message needs to get 
improved somewhat.

I plan to make testing the extended query protocol easier by making pgbench 
able to restart after a such an error (thats why I like the seperate error 
code for such cancellations...)

The problem with the error message is, that errdetail_abort() uses MyProc-
>recoveryConflictPending which is already unset when the errdetail is used. 
Unless you beat me I plan to provide a patch here (havent looked at how to do 
so yet though).

Andres

In response to

pgsql-hackers by date

Next:From: Richard HuxtonDate: 2010-02-15 10:42:15
Subject: Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl
Previous:From: Tim BunceDate: 2010-02-15 10:32:28
Subject: Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

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