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

Re: idle in txn query cancellation

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: idle in txn query cancellation
Date: 2010-02-15 08:50:08
Message-ID: 1266223808.7341.9529.camel@ebony (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

 Simon Riggs 

In response to


pgsql-hackers by date

Next:From: Leonardo FDate: 2010-02-15 09:10:09
Subject: Re: [FWD] About "Our CLUSTER implementation is pessimal" patch
Previous:From: Greg SmithDate: 2010-02-15 08:47:18
Subject: Re: [FWD] About "Our CLUSTER implementation is pessimal" patch

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