Re: Cancelling idle in transaction state - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Cancelling idle in transaction state
Date
Msg-id 1260096207.7454.57.camel@huvostro
Whole thread Raw
In response to Re: Cancelling idle in transaction state  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Cancelling idle in transaction state  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, 2009-12-06 at 07:58 +0000, Simon Riggs wrote:
> On Sat, 2009-12-05 at 18:13 -0700, James Pye wrote:
> > On Dec 5, 2009, at 12:25 PM, Simon Riggs wrote:
> > > ...
> > 
> > I'm not volunteering here, but having worked with the protocol, I do have a suggestion:
> 
> Thanks. Looks like good input. With the further clarification that we
> use NOTIFY it seems a solution is forming.

If we use notify, then "the sufficiently smart client" (tm)  should
probably declared that it is waiting for such notify , no ?

That would mean, that it should have issued either 

"LISTEN CANCEL_IDLE_TRX_<pid>"

or with the new payload enabled NOTIFY just

"LISTEN CANCEL_IDLE_TRX"

and then the NOTIFY would include the pid of rolled back backend and
possibly some other extra info. 

Otoh, we could also come up with something that looks like a NOTIFY from
client end, but is sent only to one connection that is canceled instead
of all listeners.


-- 
Hannu Krosing   http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability   Services, Consulting and Training




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Hot standby, recent changes
Next
From: Simon Riggs
Date:
Subject: Re: Hot standby, recent changes