Thread: What is a savepointLevel ?

Hello hackers,

What exactly is a savepointLevel?

They seem to have been there for 15 years[1], diligently copied from
parent transactions to children, fastidiously checked to avoid crossing
a level on rollback or release, but does anything ever change the level
from its initial value? I'm drawing a blank[2].

Regards,
-Chap


[1]

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blame;f=src/backend/access/transam/xact.c;h=fd5d6b5;hb=90cb9c3#l93

[2]
https://git.postgresql.org/gitweb/?p=postgresql.git&a=search&h=0516c61b&st=grep&s=savepointLevel

On Fri, 15 Mar 2019 at 18:18, Chapman Flack <chap@anastigmatix.net> wrote:
> What exactly is a savepointLevel?
>
> They seem to have been there for 15 years[1], diligently copied from
> parent transactions to children, fastidiously checked to avoid crossing
> a level on rollback or release, but does anything ever change the level
> from its initial value? I'm drawing a blank[2].

I had a look too, checking for uses where savepointLevel might be set
as part of a struct initialisation.  I can't find any.

There's some discussion about it in July 2004.


https://www.postgresql.org/message-id/flat/Pine.LNX.4.58.0407101609080.4563%40linuxworld.com.au#dad1807aaa73de2be7070a1bc54d0f6b

https://www.postgresql.org/message-id/flat/5902.1090695230%40sss.pgh.pa.us#53d8db46b7f452acd19ec89fcb023e71

Adding the field was committed on the 27th.

(I'm very ignorant on the following.)

It looks like the point of savepoint levels is to distinguish between
savepoints created in the top transaction level versus those created
in nested function calls, and to stop you from trying to
release/rollback to a savepoint belonging to the outer scope.  But I
don't think we support savepoints from inside functions of any kind.
Various PLs use BeginInternalSubTransaction and they handle the
rolling back/releasing internally.

So the savepointLevel variable, and the two error checks that use it,
look a bit unused.  If SAVEPOINT commands were supported in functions,
you'd want to increment savepointLevel when you made a subtransaction
on entering the function.

Does that sound approximately right?

Edmund



> [1]
>
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blame;f=src/backend/access/transam/xact.c;h=fd5d6b5;hb=90cb9c3#l93
>
> [2]
> https://git.postgresql.org/gitweb/?p=postgresql.git&a=search&h=0516c61b&st=grep&s=savepointLevel

Edmund Horner <ejrh00@gmail.com> writes:
> On Fri, 15 Mar 2019 at 18:18, Chapman Flack <chap@anastigmatix.net> wrote:
>> What exactly is a savepointLevel?
>> 
>> They seem to have been there for 15 years[1], diligently copied from
>> parent transactions to children, fastidiously checked to avoid crossing
>> a level on rollback or release, but does anything ever change the level
>> from its initial value? I'm drawing a blank[2].

> I had a look too, checking for uses where savepointLevel might be set
> as part of a struct initialisation.  I can't find any.

Yeah, I think that the field's basically been there for future use
since day one.  The SQL spec discusses savepoint levels, but as far
as I could find in some desultory searching, the only way to actually
change to a new savepoint level is to enter a function or procedure that
has the NEW SAVEPOINT LEVEL property, which is syntax we don't have.

Even though the code's dead today, I'm disinclined to remove it;
now that we have procedures, the need to treat savepoint levels
as a real feature might be closer upon us than it has been.  It
doesn't look like it's costing any significant amount of cycles
or code anyhow.

(On the other hand, maybe this is something we'd never implement.
Attaching savepoint level control to the callee, rather than the
caller, seems pretty weird to me.  AFAICS the point of a new
savepoint level would be to prevent the function from messing
with savepoints of the outer level, so I'd think what you'd want
is syntax whereby the caller can protect itself against the
callee doing that.)

            regards, tom lane