From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Andrei Zhidenkov <andrei(dot)zhidenkov(at)n26(dot)com> |
Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_cancel_backend() doesn't abort a transaction |
Date: | 2020-06-10 15:09:46 |
Message-ID: | CAKFQuwaG8kft59TMs7DNBcstQb_-RjXNBY14kst8BiMyWuHTug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wednesday, June 10, 2020, Andrei Zhidenkov <andrei(dot)zhidenkov(at)n26(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Frank Gagnepain | 2020-06-10 15:17:51 | RE: BUG #16476: pgp_sym_encrypt_bytea with compress-level=6 : Wrong key or corrupt data |
Previous Message | Andrei Zhidenkov | 2020-06-10 14:30:34 | pg_cancel_backend() doesn't abort a transaction |