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

Re: Cancelling idle in transaction state

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Kris Jurka <books(at)ejurka(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, James Pye <lists(at)jwp(dot)name>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cancelling idle in transaction state
Date: 2009-12-30 18:56:31
Message-ID: 1262199391.19367.6111.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 2009-12-30 at 14:15 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > 
> > AFAIK, NOTICE was suggested because it can be sent at any time, whereas
> > ERRORs are only associated with statements.
> > 
> > http://developer.postgresql.org/pgdocs/postgres/protocol-flow.html#PROTOCOL-ASYNC
> > "It is possible for NoticeResponse messages to be generated due to
> > outside activity; for example, if the database administrator commands a
> > "fast" database shutdown, the backend will send a NoticeResponse
> > indicating this fact before closing the connection. Accordingly,
> > frontends should always be prepared to accept and display NoticeResponse
> > messages, even when the connection is nominally idle."
> 
> Could we send an asynchronous notification immediately when the
> transaction is cancelled, but also change the error message you get in
> the subsequent commands. Clients that ignore the async notification
> would still see a proper error message at the ERROR.
> 
> Something like:
> 
> ERROR:  current transaction was aborted because of conflict with
> recovery, commands ignored until end of transaction block
> 
> instead of the usual "current transaction is aborted, commands ignored
> until end of transaction block" message.

This is possible, yes.

I have an added complication, hinted at by Joachim, currently
investigating.

-- 
 Simon Riggs           www.2ndQuadrant.com


In response to

pgsql-hackers by date

Next:From: Andres FreundDate: 2009-12-30 19:06:30
Subject: Re: Hot Standy introduced problem with query cancel behavior
Previous:From: Greg StarkDate: 2009-12-30 18:42:38
Subject: Re: Thoughts on statistics for continuously advancing columns

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