Question about savepoint level?
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t46824psql -h localhost -U postgresBuilt from patchset v2 (message #2), October 06, 2026 at 11:31 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t46824_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t46824_2 && git checkout t46824_2Patchset v2 (message #2) is on t46824_2
Hi, hackers
The TransactionStateData has savepointLevel field, however, I do not understand
what is savepoint level, it seems all savepoints have the same savepointLevel,
I want to know how the savepoint level changes.
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
On Mon, 24 Oct 2022 at 12:19, Japin Li <japinli@hotmail.com> wrote:
Hi, hackers
The TransactionStateData has savepointLevel field, however, I do not understand
what is savepoint level, it seems all savepoints have the same savepointLevel,
I want to know how the savepoint level changes.
I try to remove the savepointLevel, and it seems harmless. Any thoughts?
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
On Mon, Oct 24, 2022 at 3:00 PM Japin Li <japinli@hotmail.com> wrote:
On Mon, 24 Oct 2022 at 12:19, Japin Li <japinli@hotmail.com> wrote:
The TransactionStateData has savepointLevel field, however, I do not
understand
what is savepoint level, it seems all savepoints have the same
savepointLevel,
I want to know how the savepoint level changes.
I try to remove the savepointLevel, and it seems harmless. Any thoughts?
ISTM the savepointLevel always remains the same as what is in
TopTransactionStateData after looking at the codes. Now I also get
confused. Maybe what we want is nestingLevel?
Thanks
Richard
On 2022-Oct-24, Richard Guo wrote:
On Mon, Oct 24, 2022 at 3:00 PM Japin Li <japinli@hotmail.com> wrote:
I try to remove the savepointLevel, and it seems harmless. Any thoughts?
ISTM the savepointLevel always remains the same as what is in
TopTransactionStateData after looking at the codes. Now I also get
confused. Maybe what we want is nestingLevel?
This has already been discussed:
/messages/by-id/1317297307-sup-7945@alvh.no-ip.org
Now that we have transaction-controlling procedures, I think the next
step is to add the SQL-standard feature that allows savepoint level
control for them, which would make the savepointLevel no longer dead
code.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"You're _really_ hosed if the person doing the hiring doesn't understand
relational systems: you end up with a whole raft of programmers, none of
whom has had a Date with the clue stick." (Andrew Sullivan)
On Mon, 24 Oct 2022 at 17:56, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
This has already been discussed:
/messages/by-id/1317297307-sup-7945@alvh.no-ip.org
Sorry for my lazy search.
Now that we have transaction-controlling procedures, I think the next
step is to add the SQL-standard feature that allows savepoint level
control for them, which would make the savepointLevel no longer dead
code.
So the savepoint level is used for CREATE PROCEDURE ... OLD/NEW SAVEPOINT LEVEL
syntax [1]https://www.ibm.com/docs/en/db2/10.1.0?topic=statements-create-procedure-sql, right?
[1]: https://www.ibm.com/docs/en/db2/10.1.0?topic=statements-create-procedure-sql
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
On 2022-Oct-24, Japin Li wrote:
On Mon, 24 Oct 2022 at 17:56, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
Now that we have transaction-controlling procedures, I think the next
step is to add the SQL-standard feature that allows savepoint level
control for them, which would make the savepointLevel no longer dead
code.So the savepoint level is used for CREATE PROCEDURE ... OLD/NEW SAVEPOINT LEVEL
syntax [1], right?[1] https://www.ibm.com/docs/en/db2/10.1.0?topic=statements-create-procedure-sql
Yeah, that's what I understand. The default behavior is the current
behavior (OLD SAVEPOINT LEVEL). In a procedure that specifies NEW
SAVEPOINT LEVEL trying to rollback a savepoint that was defined before
the procedure was called is an error, which sounds a useful protection.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"El sentido de las cosas no viene de las cosas, sino de
las inteligencias que las aplican a sus problemas diarios
en busca del progreso." (Ernesto Hernández-Novich)
On Mon, Oct 24, 2022 at 6:01 PM Alvaro Herrera <alvherre@alvh.no-ip.org>
wrote:
On 2022-Oct-24, Richard Guo wrote:
ISTM the savepointLevel always remains the same as what is in
TopTransactionStateData after looking at the codes. Now I also get
confused. Maybe what we want is nestingLevel?This has already been discussed:
/messages/by-id/1317297307-sup-7945@alvh.no-ip.org
Now that we have transaction-controlling procedures, I think the next
step is to add the SQL-standard feature that allows savepoint level
control for them, which would make the savepointLevel no longer dead
code.
Now I see the context. Thanks for pointing that out.
Thanks
Richard