Ivan_Pisarevskyчто вызовет полное кэширование резалтсета и сортировку через темп файл,т.е. это такой хак, чтобы стабилизировать курсор.

Любопытные приёмчики...

А если бы в исходном цикле поменять условие на сам курсор?




тогда бы могло зациклиться?

возможно, для двойки это был бы более очевидный хак

правда для тройки не рекомендуется, но там вроде само должно работать

А, ещё старый добрый хак

hvlad,

я тоже не вполне понимаю, почему ТС начал цикл городить, вместо того, чтобы просто запустить UPDATE
похоже на него так со всех сторон насели, что мозг заклинило, включилось туннельное зрение, бывает, брррр!

но он начал с цикла, так что мне стало любопытно сделать именно его изначальный цикл работающим с минимальными изменениями в запросе.

И да, where current - именно чтобы не искать запись ещё раз, тем более full-scan'ом, аналог прямогo update.

Но тут снова вопрос к implementation details.
Любое изменение - это новая версия строки.

Не может ли так получиться, что update вставит новую версию записи в свободное место впереди курсора, после чего бегущий fullscan'ом цикл снова на нее наткнётся?

Вроде краем уха слышал, что записи помечались, что они изменены текущим оператором, чтобы этого избежать, но где когда и что слышал, не помню.

Симонов Денис,

а в 2.х ?

может вышеупомянутый update ( отдельный или внутри цикла ) снова зацепить созданные сами собой записи ?

а update с where видимо опять может...

3.0 relnotescontinue updating the same rows ad infinitum ..... because the engine used an implicit cursor for the operations.

Симонов Денисupdate без where нет

а почему, интересно?

предположим, на текущей сранице свободного места нет.
оператор изменённую запись записывает в свободное место на следующую страницу.
а если после restore - так и вообще на чистую новую страницу в конец таблицы.

....через некоторое время update который fullscan заканчивает текущую страницу, добирается до следующей - а там новая изменённая версия ему снова попадается.

hvladАпдейт создаёт бекверсии, но голова цепочки версий всегда живёт по старому адресу.

ага, понятно, это я видимо после недавней статьи PostgresSQL vs InnoDB попутал

но тут тоже неполнятно, ведь записи в FB пакуются побайтово в RLE

это означает, что обновлённая запись может оказаться менее удачной для RLE и после упаковки стать длиннее старой версии, и просто "не влезть" в местое, которое занимала старая запись?

Dimitry SibiryakovЗапись привязана к странице и не может перемещаться

а если изменённая запись стала длиннее (после упаковки, в байтах), а не странице свободного места нет ?

Будут другие записи выноситься на другие страницы ?

hvlad,

ага, так понятно, спасибо

сразу появляется тролльское желание зарезать кэш БД в ровно одну страницу и попробовать вычитать такую запись, сможет ли сервер разумно обработать такую ошибку

hvlad,

можно сказать, что уползание головы на другую страницу и/или на другое место в той же странице (в любой момент, по любой причине) - проявляется как изменение RDB$DB_KEY ? Что это один и тот же процесс ?

И соотв. читая рассуждения про как-бы-стабильность значений RDB$DB_KEY можно оценить, в каких случаях головы ползают, а в каких остаются на месте ?

Dimitry Sibiryakov,

если тебя и KDV объединить, то получается, что RDB$DB_KEY не меняется никогда.
а это не так, иначе бы его использовали вместо синтетических ПК и не парились

например, из известной статьи

This also leads well to a discussion why you cannot rely on the record position to persist
1) after a backup/restore
2) or after your transaction has committed