I'd be very grateful to any hackers out there who are looking for a
project before close of 8.5 to consider working on this. It's dang
useful, both for Hot Standby and normal processing.
(You'll have the added bonus of proving you're smarter than me!)
On Wed, 2009-01-21 at 15:22 -0500, Bruce Momjian wrote:
> Added to TODO:
>
> Allow administrators to cancel multi-statement idle
> transactions
>
> This allows locks to be released, but it is complex to report the
> cancellation back to the client.
>
> * http://archives.postgresql.org/pgsql-hackers/2008-12/msg01340.php
>
> ---------------------------------------------------------------------------
>
> Simon Riggs wrote:
> > Currently SIGINT is ignored during <IDLE> in transaction, but we have
> > recently agreed to allow this to cancel the transaction. We said we
> > would do this in all cases, so this is a separate feature/patch (though
> > Hot Standby requires it).
> >
> > A simple change allows the transaction to be cancelled, but there are
> > some loose ends that I wish to discuss.
> >
> > If we are running a statement and a cancel is received, then we return
> > the ERROR to the client, who is expecting it. If we cancel a transaction
> > while the connection is idle, we have no way of signalling to the client
> > program this has occurred. So the client finds out about this much
> > later, not in fact until the next message is sent.
> >
> > Is there a mechanism for communicating the state back to the client?
> > Will this be handled correctly with existing code? psql appears to be
> > confused by a cancelled backend.
> >
> > I'm not familiar with these aspects of the code, so some clear
> > suggestions are needed to allow me to work this out. I'm worried that
> > this will delay things further otherwise.
> >
> > --
> > Simon Riggs www.2ndQuadrant.com
> > PostgreSQL Training, Services and Support
> >
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
-- Simon Riggs www.2ndQuadrant.com
