BUG #16867: savepoints vs. commit and chain

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: tureba(at)gmail(dot)com
Subject: BUG #16867: savepoints vs. commit and chain
Date: 2021-02-15 20:53:41
Message-ID: 16867-3475744069228158@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 16867
Logged by: Arthur Nascimento
Email address: tureba(at)gmail(dot)com
PostgreSQL version: 13.2
Operating system: CentOS
Description:

Hi all,

I'm seeing an unexpected behavior when using savepoints along commit and
chain. I couldn't find a mention of it in the docs and the regression tests
seem to not cover it.

On a trivial transaction, I might do:

=# begin;
*=# commit and chain;
*=# -- In this point I'm inside a second transaction

However, if the first transaction contained any unreleased savepoints, the
chain does not get me to a second transaction:

=# begin;
*=# savepoint foo;
*=# commit and chain;
=# -- In this point I'm not inside a second transaction

I first noticed it when using psql's ON_ERROR_ROLLBACK, but it can be
reproduced without it, as shown above.

I also thought it might be psql's fault at not knowing that COMMIT can also
return the state PQTRANS_INTRANS in
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/psql/common.c;h=6f507104f464fde615fb7628f195b0e2149b40ee;hb=HEAD#l1349

But even trying a local fix (by adding COMMIT to the possible commands) to
that didn't quite solve it, so there might be something else.

Let me know what I might be missing in this.

Thanks,
Arthur Nascimento

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Arthur Nascimento 2021-02-15 21:47:29 Re: BUG #16867: savepoints vs. commit and chain
Previous Message Tom Lane 2021-02-15 15:18:46 Re: BUG #16846: "retrieved too many tuples in a bounded sort"