I.e. only the second update gets undone. Required prerequisite to step on this bug:

* Selectable stored procedure
* Multiple updates of the same record inside (so that update-in-place happens)
* Those multiple updates belong to different savepoint levels (nested begin/end blocks)
* Suspend is performed from the deepest savepoint level (same or deeper than the last update)
* Transaction or savepoint rollback is issued afterwards

Perhaps the complete list is very rare in practice. Otherwise I'm clueless why nobody had noticed this issue during the past 10 years, as this bug is inherited from InterBase.

The fix will be committed into all the branches soon.

Description

Test case:
create table tab (col int);
commit;
insert into tab (col) values (1);
commit;
create procedure proc returns (ret int)
as
begin
update tab set col = 2;
begin
update tab set col = 3;
ret = 1;
suspend;
end
when any do
begin
ret = 0;
suspend;
end
end
commit;
select col from tab; -- returns 1
commit;
select ret from proc;
rollback;
select col from tab; -- returns 2!!!
commit;
I.e. only the second update gets undone. Required prerequisite to step on this bug:
* Selectable stored procedure
* Multiple updates of the same record inside (so that update-in-place happens)
* Those multiple updates belong to different savepoint levels (nested begin/end blocks)
* Suspend is performed from the deepest savepoint level (same or deeper than the last update)
* Transaction or savepoint rollback is issued afterwards
Perhaps the complete list is very rare in practice. Otherwise I'm clueless why nobody had noticed this issue during the past 10 years, as this bug is inherited from InterBase.
The fix will be committed into all the branches soon.