AkinaПришлось решать одноразовую задачу.

Таблица, содержащая группы записей по некоему полю. Группы подвергались обработке, в итоге получался набор записей той же структуры, но с модифицированными данными (в т.ч. с изменением количества записей в группе). Итоговые данные должны были лечь на место исходных.

Задача была решена запросом, схематически выглядящим так:




Итоговый результат - правильный.

Однако возник вопрос - гарантируется ли правильное выполнение подобной схемы? Действительно ли выполнение запроса идёт так: сперва полное выполнение cte1 и кэширование окончательного результата, затем очистка таблицы, затем копирование кэшированного результата в таблицу? Или возможна такая неприятность, что будет кэширован результат со ссылками на исходные записи, а не со значениями, и в результате часть данных будет утрачена?

думаецца, что записи, закомиченные инсертами других сессий между снапшотом КТЕ и началом делета, удалены не будут. по поводу коммита апдейта в этом же интервале слету не скажу. надо проверить, в какой момент делет в кте лочит записи. кажется, что должен на момент снепшота кте (даже при рид--коммитеде). т.е . другие коммитеры, пришедшие за данными удаляемых строк после снепшота кте, должны встать в очередь (и не увидеть их после делета).

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

AkinaVSVLADИтого, как я понял, запросы в WITH выполняются параллельно (в случайном порядке).Это невозможно.

Последующие по тексту CTE могут использовать результаты предыдущих.
"выполняться" не атомарное понятие.
все записи , которые д.б. изменены в кте должны быть залочены на момент "снепшота кте". т.е. делете не должен ещё стартовать , якобы, но залочить строки на изменение уже должен. т.е. должен "начать "выполняться " в части наложения блокировок.

второй вариант -- лочить отложенно -- но столько раз рестартовать кте полностью, сколько раз нарушится "унутренний рипитбл-рид" к моменту делета -- чтобы выдержать единство снепшота для всех коленец кте

грубо говоря там скорее всего ([не]?явные) ошибки сериализации возможны для случая сложного исчисления изменяемых в дальнейшем строк в предселектах. или долгий "вейт с повторами пред--исчисления" (рестарт снепшота кте -- т.к. изменяемые строки должны удовлетворять репитеблу внутре кте. т.е. надо смотреть реализацию, чтобы понять, как лучше. )

Akina,

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

скорее всего примерно так же , как и более высокие уровни изоляции -- к моменту обработки записи в очередном коленце проверяется отсутствие конкурирующих изменений в блокируемых но не измененных нами же записях с момента снапшота , тако же как отсутствие лока( -- который требует отложить общий снепшот). а оверхед в транзакционной субд -- он проза жызни . о чом и пробую предупредить. не ходите дети в африку гулять. т.е. сразу взять делет -- оно дешевле может выйти.

и причом тут оконные хункции , если в пж есть даже модифицирующие.

Akinaкогда запись одного CTE, которая должна быть залочена при выполнении другого CTE, ещё не получена, т.е. попросту не существует. Вы представляете себе процесс блокирования несуществующей записи?


А ведь для оконных функций появление ещё одной записи в группе запросто может потребовать не только блокировки "свежей" записи, но и блокировки/разблокировки ранее существовавших записей - т.е. фактически похерь всё сделанное ранее и начинай всю работу с самого начала.

не истерите
запись невидимая до снепшота "не существует" для всех коленец кте и для любых хотя бы и дверных функций а не токмо оконных. пж это определяет по служебным полям.