Симонов Денистот что внутри файла. Ты о нём знаешь. В FB есть UNDO лог. И он там всегда был, иначе как бы он откатывал транзакции.
транзакции откатить можно и без undo, через TIP. Использования undo при rollback в некоторых случаях - это всего лишь оптимизация. А вот сейвпойнты - без undo никак. И undo не хранится внутри файла, строго говоря это сочетание версий в базе, версий в temp space и управляющих структур в памяти.

Yo.!у меня честно говоря стойкое ощущение, что тот кто писал релиз ноты, как и в прошлый раз, слегка не понимает в чем проблема. на уровне snapshot и так все в "undo log" смотрят.
...
была проблема в том, что он перезапускался в цикле, а не в том что видел свои изменения.
а у меня стойкое ощущение, что проблему не понимаешь ты. Ну или не хочешь понимать.

Dimitry SibiryakovОн всё равно не успокоится, пока...
продолжать фразу не обязательно :-)

Yo.!т.е. в релиз нотах снова пишут люди не понимающие чего пишут. не везучие у вас рилиз ноты на тему cursor stability
какие конкретно претензии к релизным нотам? Пересмотрел еще раз, вроде все верно написано.

Yo.!на счет delete from test where test.ID in (select id from test GROUP BY id HAVING count(id)>1);
можете внятно пояснить, что там происходит и чем там может помочь заглядывание в мифический undo log ? уровень изолированности snapshot/serializable
транзакция всегда видит свои собственные изменения, будь она хоть трижды снапшотом. Раньше, если курсор натыкался на измененные внутри него же записи, он их считал видимыми. Сейчас не считает (путем проверки посредством undo-лога). А какие именно формы имел курсор - пофиг. Undo-лог это изменения не только текущей транзакции, но и текущего сейвпойнта. По нему легко выполняется проверка текущей версии записи и при необходимости чтение предыдущей. Вот и вся кухня за словами cursor stability.

сизиф и мартышки,

1) dblink-и уже перешли из контрибов в ядро? Я надеюсь, что они относятся к "they address a limited audience", а не к "too experimental to be part of the main source tree"?

2) Предлагаю таки почитать про автономные транзакции - в википедии или в оракловой доке, например. После чего предложить реальный сценарий возникновения в них дедлоков с родительской транзакцией.

Сергей Арсеньев,

принято, дедлок возможен при WAIT-режиме транзакций. Тем не менее:

SQL> create table t (id int primary key);
SQL> insert into t (id) values (1);
SQL> set term ^;
SQL> execute block as begin in autonomous transaction do insert into t values (1); end^
-- пауза в DeadlockTimeout секунд
Statement failed, SQLSTATE = 23000
violation of PRIMARY or UNIQUE KEY constraint "INTEG_2" on table "T"
-Problematic key value is ("ID" = 1)

hvlad,

дык без PK и дедлока не будет, оффтопик нам не нужен :-)