Re: what happens if a failed transaction is not rolled back?

On Mon, Apr 24, 2023 at 4:20 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Mon, Apr 24, 2023 at 12:56 PM David Wheeler <hippysoyboy(at)gmail(dot)com>
> > wrote:
> >> Now I’m curious. Does it have the same impact on performance that an
> idle
> >> in transaction connection has? Eg does it prevent vacuum? Does it still
> >> hold locks?
>
> > Absent documentation to the contrary I would expect the system to at best
> > be in an idle-in-transaction state as-if the failed command never was
> > executed.
>
> A quick experiment will show you that we release locks as soon as the
> transaction is detected to have failed. I believe the same is true of
> other interesting resources such as snapshots (which'd be what affects
> vacuum) but it's less easy to observe that from the SQL level. At least
> by intention, a failed transaction won't hold any resources that would
> impact other sessions.
>
> > The concept of savepoints, whether in use in a particular
> > transaction, would require at least that much state be preserved.
>
> Of course, we can't release resources that were acquired by a still-live
> subtransaction, a/k/a savepoint.
>

I think testing pg_stat_activity.backend_xid being not null does the trick.
If it's null, it either never took an xid by doing something that is worth
having one assigned after transaction start (including immediately after
procedure commit;), or had one that was released when aborted (if there is
an active savepoint it would keep backend_xid not null). Of course, you
can't do that from the aborted transaction until it's rolled back first.

Hm. I also noticed when looking at this that aborted transactions with
savepoints are not subjected to the idle_in_transaction timeout which is a
bit surprising.
.

merlin