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
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
