мне нужно во второй ожидающей транзакции, когда она выйдет из ожидания, увидеть, какие изменения внесены первой(статус измененный, например)
выглядит так, что этого не будет, читаю вот доку, может, мы разное видим, и я неправ?
https://postgrespro.ru/docs/postgrespro/13/transaction-iso#XACT-REPEATABLE-READ

решил не заморачиваться со средой ибо на никсах

локал выдает It worked!
Congratulations on your first Django-powered page.
Next, start your first app by running python manage.py startapp [app_label].

You're seeing this message because you have DEBUG = True in your Django settings file and you haven't configured any URLs. Get to work!

а вот Page not found (404)
Request Method:  GET
Request URL:  http://localhost:8000/polls/
Using the URLconf defined in mysite.urls, Django tried these URL patterns, in this order:

^admin/
The current path, polls/, didn't match any of these.

You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False, and Django will display a standard 404 page.

Тогда read_commited?

Может ты урлы прописать забыл?

выглядит как те же яйца:)

Нет. Коммитед не будет лочить данные для чтения, в отличии от repeatable_read.

Стандарт SQL определяет четыре уровня изоляции транзакций. Наиболее строгий из них — сериализуемый, определяется одним абзацем, говорящем, что при параллельном выполнении несколько сериализуемых транзакций должны гарантированно выдавать такой же результат, как если бы они запускались по очереди в некотором порядке. Остальные три уровня определяются через описания особых явлений, которые возможны при взаимодействии параллельных транзакций, но не допускаются на определённом уровне.(с)
но, блин, это же медленно!

Зависит от субд.

Говорят постгрес остается быстрой даже с repeatable_read.

неплохо бы ей оставаться быстрой и в Serializable режиме:)

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

Ну то есть это не только к постгрес относится.

почитал внимательно, мне как раз и нужно видеть изменения, проблема в том, как это в django поймать, видится такой механизм, но он какой-то костыльный:
1) получать блокировку
2) а уже после получения выполнения получать выборку свежую и тогда менять уже
но выглядит это осень странно

или все же внутри транзакции после получения исполнения второй данные перезапоросятся при самом select_for_update?

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

Зачем это в джанге ловить?

Ну как-бы вся работа с режимами изоляции происходит на стороне бд.

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

Тогда repeatable_read?