Nested Transactions

#1

Hi,

postgres supports nested transactions by using savepoints.
Unfortunately savepoints get lost after a commit.

Is there any plan to support nested transactions with
several (stacked) begin/commit statements?

I guess that it does *not* require a big code change:
If "begin" is used during a transaction it should behave
like a savepoint. And "commit/rollback" removes the last
element from the stack and does a real commit if the stack
gets empty.

Thomas

--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

#2

Thomas Guettler <hv (AT) tbz-pariv (DOT) de> wrote:

Quote:

postgres supports nested transactions by using savepoints.
Unfortunately savepoints get lost after a commit.

Is there any plan to support nested transactions with
several (stacked) begin/commit statements?

I don't know for sure, but I don't find "nested transactions" in the TODO
list.

Quote:

I guess that it does *not* require a big code change:
If "begin" is used during a transaction it should behave
like a savepoint. And "commit/rollback" removes the last
element from the stack and does a real commit if the stack
gets empty.

It is not that simple.
A nested transaction must be able to commit even if the surrounding
transaction rolls back. You cannot do that with savepoints.

Yours,
Laurenz Albe

#3

Thomas Guettler <hv (AT) tbz-pariv (DOT) de> wrote:

Quote:

postgres supports nested transactions by using savepoints.
Unfortunately savepoints get lost after a commit.

Is there any plan to support nested transactions with
several (stacked) begin/commit statements?

I don't know for sure, but I don't find "nested transactions" in the TODO
list.

Quote:

I guess that it does *not* require a big code change:
If "begin" is used during a transaction it should behave
like a savepoint. And "commit/rollback" removes the last
element from the stack and does a real commit if the stack
gets empty.

It is not that simple.
A nested transaction must be able to commit even if the surrounding
transaction rolls back. You cannot do that with savepoints.

Yours,
Laurenz Albe

#4

Thomas Guettler <hv (AT) tbz-pariv (DOT) de> wrote:

Quote:

postgres supports nested transactions by using savepoints.
Unfortunately savepoints get lost after a commit.

Is there any plan to support nested transactions with
several (stacked) begin/commit statements?

I don't know for sure, but I don't find "nested transactions" in the TODO
list.

Quote:

I guess that it does *not* require a big code change:
If "begin" is used during a transaction it should behave
like a savepoint. And "commit/rollback" removes the last
element from the stack and does a real commit if the stack
gets empty.

It is not that simple.
A nested transaction must be able to commit even if the surrounding
transaction rolls back. You cannot do that with savepoints.

Yours,
Laurenz Albe

#5

Thomas Guettler <hv (AT) tbz-pariv (DOT) de> wrote:

Quote:

postgres supports nested transactions by using savepoints.
Unfortunately savepoints get lost after a commit.

Is there any plan to support nested transactions with
several (stacked) begin/commit statements?

I don't know for sure, but I don't find "nested transactions" in the TODO
list.

Quote:

I guess that it does *not* require a big code change:
If "begin" is used during a transaction it should behave
like a savepoint. And "commit/rollback" removes the last
element from the stack and does a real commit if the stack
gets empty.

It is not that simple.
A nested transaction must be able to commit even if the surrounding
transaction rolls back. You cannot do that with savepoints.

Yours,
Laurenz Albe

#6

Thomas Guettler <hv (AT) tbz-pariv (DOT) de> wrote:

Quote:

postgres supports nested transactions by using savepoints.
Unfortunately savepoints get lost after a commit.

Is there any plan to support nested transactions with
several (stacked) begin/commit statements?

I don't know for sure, but I don't find "nested transactions" in the TODO
list.

Quote:

I guess that it does *not* require a big code change:
If "begin" is used during a transaction it should behave
like a savepoint. And "commit/rollback" removes the last
element from the stack and does a real commit if the stack
gets empty.

It is not that simple.
A nested transaction must be able to commit even if the surrounding
transaction rolls back. You cannot do that with savepoints.

Yours,
Laurenz Albe

#7

Thomas Guettler <hv (AT) tbz-pariv (DOT) de> wrote:

Quote:

postgres supports nested transactions by using savepoints.
Unfortunately savepoints get lost after a commit.

Is there any plan to support nested transactions with
several (stacked) begin/commit statements?

I don't know for sure, but I don't find "nested transactions" in the TODO
list.

Quote:

I guess that it does *not* require a big code change:
If "begin" is used during a transaction it should behave
like a savepoint. And "commit/rollback" removes the last
element from the stack and does a real commit if the stack
gets empty.

It is not that simple.
A nested transaction must be able to commit even if the surrounding
transaction rolls back. You cannot do that with savepoints.

Yours,
Laurenz Albe

#8

Thomas Guettler <hv (AT) tbz-pariv (DOT) de> wrote:

Quote:

postgres supports nested transactions by using savepoints.
Unfortunately savepoints get lost after a commit.

Is there any plan to support nested transactions with
several (stacked) begin/commit statements?

I don't know for sure, but I don't find "nested transactions" in the TODO
list.

Quote:

I guess that it does *not* require a big code change:
If "begin" is used during a transaction it should behave
like a savepoint. And "commit/rollback" removes the last
element from the stack and does a real commit if the stack
gets empty.

It is not that simple.
A nested transaction must be able to commit even if the surrounding
transaction rolls back. You cannot do that with savepoints.

Yours,
Laurenz Albe

#9

Thomas Guettler <hv (AT) tbz-pariv (DOT) de> wrote:

Quote:

postgres supports nested transactions by using savepoints.
Unfortunately savepoints get lost after a commit.

Is there any plan to support nested transactions with
several (stacked) begin/commit statements?

I don't know for sure, but I don't find "nested transactions" in the TODO
list.

Quote:

I guess that it does *not* require a big code change:
If "begin" is used during a transaction it should behave
like a savepoint. And "commit/rollback" removes the last
element from the stack and does a real commit if the stack
gets empty.

It is not that simple.
A nested transaction must be able to commit even if the surrounding
transaction rolls back. You cannot do that with savepoints.

Yours,
Laurenz Albe

#10

Laurenz Albe schrieb:

Quote:

Thomas Guettler <hv (AT) tbz-pariv (DOT) de> wrote:
postgres supports nested transactions by using savepoints.
Unfortunately savepoints get lost after a commit.
....

Quote:

It is not that simple.
A nested transaction must be able to commit even if the surrounding
transaction rolls back. You cannot do that with savepoints.

Hi,

for me the surrounding transaction is the first one (see below). If it
rolls back, everything should be rolled back. At least that what
sybase and mssql server do.

begin; -- 1 (surrounding transaction)
begin; -- savepoint tran2
update ...
commit; -- does nothing. rollback would restore to tran2
commit; -- does real commit, rollback would rollback

Microsoft http://msdn.microsoft.com/en-us/library/ms189336.aspx
Sybase http://manuals.sybase.com/onlinebook...;pt=53608;uf=0

Thomas

--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de