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

Мне кажется ты что-то нереальное просишь.

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

И в то же время, тебе надо, чтобы такое отслеживаение происходило в течении всей транзакции.

Может тебе тогда транзакцию раздробить нужно?

да почему?
1) первая транзакция меняет данные
2) в этот момент создаётся вторая, видит заблокированное и ждёт
3) после снятия блокировки она получает управление, берет свежий снимок того, что наделала первая
4) если изменения ее устраивают, выполняется дальше, если нет - откатывается

Так это repeatable_read.

так вторая же для этого и ждёт конца выполнения первой, когда ей самой разрешат

нет! в нем хоть сколько селектов потом делай, он никогда не увидит свежего от 1й транзакции

Он увидит свежие изменения сразу после снятия блокировки камон.

короче, все ещё мутнее, хехе
Repeatable read вторую транзакцию не выполнит, т.к. первая поменяла данные
в таком случае ее перезапускать надо

Ну, тебе же это и нужно, нет?

Ты же тут написал про перепрочтение.

получается, да, но я так понимаю, заново транзакцию я должен пересоздать

Команды UPDATE, DELETE, SELECT FOR UPDATE и SELECT FOR SHARE ведут себя подобно SELECT при поиске целевых строк: они найдут только те целевые строки, которые были зафиксированы на момент начала транзакции. Однако к моменту, когда они будут найдены, эти целевые строки могут быть уже изменены (а также удалены или заблокированы) другой параллельной транзакцией. В этом случае транзакция в режиме Repeatable Read будет ожидать фиксирования или отката первой изменяющей данные транзакции (если она ещё выполняется). Если первая изменяющая транзакция откатывается, её результат отбрасывается и текущая транзакция может продолжить изменение изначально полученной строки. Если же первая транзакция зафиксировалась и в результате изменила или удалила эту строку, а не просто заблокировала её, произойдёт откат текущей транзакции с сообщением

ОШИБКА: не удалось сериализовать доступ из-за параллельного изменения
так как транзакция уровня Repeatable Read не может изменять или блокировать строки, изменённые другими транзакциями с момента её начала.

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

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

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

вот я механизм и спрашивал, ага, спасибо
приятно утром в субботу узнавать что-то новое

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

по идее ещё с тем же успехом можно использовать nowait=True
ждать, когда освободится

Ну вот и отлично.