Re: Cancelling idle in transaction state

On Sat, Dec 5, 2009 at 8:13 PM, James Pye <lists@jwp.name> wrote:
> I think the answer here is that the server should *not* report the cancellation.
>
> Rather, it should mark the transaction as failed and let the client eventually sync its state on subsequent requests
thatwill result in InFailedTransaction ERRORs. 
>
[...]
> Also, if immediate notification is seen as a necessity, a WARNING with a special code could be leveraged. Oh, or
maybeuse a dedicated LISTEN/NOTIFY channel? "LISTEN pg_darn_admin_zapped_my_xact;" to opt-in for transaction
cancellationevents that occur in *this* backend.. [Note: this is in addition to COMMITs emitting ERRORs] 

I think this line of thinking is on the right track.  The server
should certainly not send back an immediate ERROR response, because
that will definitely confuse the client.  Of course, any subsequent
commands will report ERRORs until the client rolls back.  But it also
seems highly desirable for the server to send some sort of immediate,
asynchronous notification, so that a sufficiently smart client can
immediately report the error back to the user or take such other
action as it deems appropriate.

Currently, it appears that the only messages that the server can send
back asynchronously are ParameterStatus and NotificationResponse.  So
we need to decide whether it's feasible/better to shoehorn this
functionality into one of those message types, or whether we should
bump the protocol version and add a new message type (cue: panic in
the streets).  On first examination (and I am not an expert in this
area), ParameterStatus would seem to be the better choice, because it
appears to me that all clients must be prepared to cope with such
messages, whereas in theory a client might be unprepared for a
NotificationResponse if it never executes LISTEN.  (It seems clearly
preferable not to require clients to issue an explicit LISTEN in order
to enable this feature.)

Going with that theory, we could pick a "magical" parameter status
value, either something like __transaction_cancelled, or maybe even
something that contains a character that isn't even legal in a normal
parameter, like $transaction_cancelled, if we don't think that will
break any clients.  Then we could just report a value change for this
whenever an idle transaction is cancelled.  Clients who ignore this
will find out when they next issue a query; others will know
immediately.

...Robert