On Sat, Dec 5, 2009 at 8:13 PM, James Pye <li...@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 that will result in > InFailedTransaction ERRORs. > [...] > Also, if immediate notification is seen as a necessity, a WARNING with a > special code could be leveraged. Oh, or maybe use a dedicated LISTEN/NOTIFY > channel? "LISTEN pg_darn_admin_zapped_my_xact;" to opt-in for transaction > cancellation events 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
