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
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" |