Re: pg_cancel_backend() doesn't abort a transaction - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: pg_cancel_backend() doesn't abort a transaction
Date
Msg-id CAKFQuwaG8kft59TMs7DNBcstQb_-RjXNBY14kst8BiMyWuHTug@mail.gmail.com
Whole thread Raw
In response to pg_cancel_backend() doesn't abort a transaction  (Andrei Zhidenkov <andrei.zhidenkov@n26.com>)
Responses Re: pg_cancel_backend() doesn't abort a transaction  (Andrei Zhidenkov <andrei.zhidenkov@n26.com>)
List pgsql-bugs
On Wednesday, June 10, 2020, Andrei Zhidenkov <andrei.zhidenkov@n26.com> wrote:

The result is that status = 'y' WHERE foo = 1 , so Session 1 committed the transaction successfully. I am missing something or the commentary is vague?

P.S. It's not clear from the documentation whether pg_cancel_backend() aborts transaction or not

User-facing docs seem reasonably clear: “ Cancel a backend's current query. “

It makes it so that current query fails, nothing more.  If that query is part of a transaction it will typically cause subsequent statements to fail since the transaction is in an aborted state.  However, if the transaction can cope with that statement failing, as your example does using savepoints, the transaction can continue onto normal completion.

From what you say the source code comments seem to be written for the common case, but “query-cancel” should/does impact just a single query and does not target the transaction directly.

It does not seem desirable that the containing transaction be affected directly nor surely does changing the behavior make sense at this point.

David J.

pgsql-bugs by date:

Previous
From: Andrei Zhidenkov
Date:
Subject: pg_cancel_backend() doesn't abort a transaction
Next
From: Frank Gagnepain
Date:
Subject: RE: BUG #16476: pgp_sym_encrypt_bytea with compress-level=6 : Wrongkey or corrupt data