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

Simon Riggs wrote:
> On Fri, 2010-01-01 at 12:53 +0200, Heikki Linnakangas wrote:
>> I agree with Joachim's comments upthread that we should have a different
>> function for forcefully aborting the whole transaction, and leave the
>> current pg_cancel_backend() behavior alone. 
> 
> That would require multiple behaviours. Joachim already proposed
> multiplexing SIGINT and Tom disagreed, on the simultaneous thread "Hot
> Standby introduced problem with query cancel behaviour". I agree that
> there seems little point in multiplexing both signals.
> 
> So the only way to have multiple cancel behaviours is to do this
> cancellation via SIGUSR1 options and have additional functions to
> request them.
> 
> Which amounts to rejecting this patch, since *this* patch changes the
> behaviour of SIGINT for all senders, which is what I understood people
> desired, i.e. not just a change for Hot Standby. I assumed Joachim did
> not mean to veto his own patch, but I'm not sure what you think here?
> (I don't mind either way).

I don't know, I don't feel strongly about this. Is there really no other
way?

>> In any case, the
>> documentation of pg_cancel_backend() or the new function needs to
>> explain what exactly it does.
> 
> ...The patch changes the docs for pg_cancel_backend().

I don't think that's enough. "Cancel a backend's current query or abort
an idle transaction" leaves a lot of questions. When does it abort the
transaction? The whole top-level transaction or just the current
subtransaction?

>> I believe people liked the idea of giving a different ERROR message when
>> a transaction is canceled because of conflict with recovery. It would
>> also be good to give a different error message when an idle transaction
>> is canceled using query cancel. Otherwise you don't know what hit you,
>> especially if you're not paying attention to NOTICEs.
> 
> I did like that idea when I heard it, but it seemed to have a few
> problems on implementation.
> 
> Currently we say 
> 
> ERROR:  current transaction is aborted, commands ignored until end of
> transaction block
> 
> and we repeat this every time a new statement is sent other than COMMIT
> or ROLLBACK.
> 
> We could either endlessly repeat this
> 
> ERROR:  current transaction is aborted because of conflict with
> recovery, commands ignored until end of transaction block
> 
> or just say it once and then revert to the normal message. Neither
> seemed very useful.

Seems useful to me, so that you know why your transaction was cancelled.
It's rather weird to see no ERRORs in the previous steps, and suddenly
you see that the transaction is aborted. And none your savepoints exist
anymore either.

> I'm also not sure why we would want to single out Hot Standby to
> generate the reason "because of conflict with recovery" when no other
> ERROR source would generate such a reason.

Because you don't get any other ERROR for it. If your transaction is
aborted because of e.g a unique key violation, you get the ERROR about
unique key violation first, and only the subsequent commands produce the
"current transaction is aborted" message. With hot standby conflicts,
the first and only symptom the client sees is that the subsequent
commands fail with "current transaction is aborted", so it would be nice
to know why.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com