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

Представим, что часы идеально синхронизированы. Запрос послали в 9:00.000.
Запрос
1. шёл по сети 100мс
2. время на планирование 30мс
3. время когда он в локе посидел 1с
4. время выполенения всего запрос ещё 2 сек.

Ну цифры же могут быть разные в разных пунктах.

Чем простой повтора отличается от того, что запрос "шёл" до бэкенда? Я не понимаю.

В этом случае существенного отличия нет. Т.е. в этом отношении у меня получился плохой пример. :(
Но я просто хотел показать что-то, для чего очевидно, что значения, передаваемые с клиента, могут меняться при повторах транзакции (время), независимо от состояния СУБД.

Я думаю, что можно придумать пример, где повтор запроса приводит к неправильно логике. Наверно что-то с локами можно придумать.
Типо мы залочили что-то, потом сделали какую-то логику в зависимости от данных. Потом словили ошибку и повторять эту же всю логику уже не нужно, так как она скорей всего другая с другими данными.

Выше ответил.

Но в этом случае можно указать, чтобы не было повтора.
У меня же повтор - это опциональная штука))

Делать нужно по ТЗ, а не выдумкам разраба =)

Так Константин же писал про повторы одностайтментовых транзакций ( https://t.me/pgsql/225459 ).

Т.е. в них вся "логика", зависящая от текущего состояния базы данных, неизбежно будет в самом таком statement.
И, в тех случаях, когда ни от чего "внешнего" они не зависят (данных с клиента) — почему бы их не повторить автоматически?

В ТЗ тоже пишут, что делать если вы словили serialization failure?))

Если реализовать так — да, почему бы нет?
Вопрос только — кому это нужно (если Вам — patches welcome ;) )?

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

У вас достаточно подробный ТЗ. Мне задачи так не ставят.

Ну если мы повторяем одни и те же транзакции, то использование какого-то правили для выбора жертвы действительно гарантирует, что мы тут не завязнем. Но если транзакция каждый раз пытается блокировать разные объекты, то это не поможет.
Но в общем это бессодержательный спор.
Да, проблемы с дедлок детешинов в ПГ есть, но они на мой взгляд вызваны не отсутствием "приоритизации", а тем, что каждый бэкенд занимается этим сам. А тут бы не помешала некторая централизация. Я хотя если у нас возникает много непересекающизхся циклов,  то подход постгреса предпочтительнее.

Касательно изначального предмета дискуссии (если я правильно помню с чего всё началось), то (на мой взгляд):
1. Дедлоки не неизбежное зло (т.е. "implicit rollbacks неизбежны при наличии параллельных конкурирующих за ресурсы транзакций" вообще говоря не правда). Если приложение в состоянии контролировать порядок запроса блокировок, то их можно избежать.
2.  Дедлоки  не желательно рассматривать как штатную ситуацию, потому как время их обнаружения в Пг достаточно большое (секунда по умолчанию). А уменьшение .deadlock timeout может привести параличу системы, которая ьудет аниматься исключительно поиском дедлоков, даже если их нет.
3. Если же дедлоки возникают крайне редко, приложение допускает секундные задержки с ответом и логика работы приложение достаточно сложна, чтобы пытаться обеспечить детерминированный порядок взятия блокировок, то тогда можно просто отлавливать ошибку и рестартовать транзакцию.

Мне так тоже не ставят - я сам прокачиваю с заказчиком, чтобы потом не было мучительно больно на тесте и загоне в прод

Народ, а подскажите, есть ли какой способ вывести значения Bind-переменных запроса, который вижу в pg_stat_statements, например? А то отображается только $1, $2 и т.д.

Какая-то трассировка может...

логи?

В логах также отображаются с долларами же...

ещё расширение было pg_qualstats, вроде оно что-то такое может

> Но если транзакция каждый раз пытается блокировать разные объекты, то это не поможет.

Покажите мне ситуацию, когда это не поможет.
Допустим, "приоритет" состоит в том, что в deadlock resolution всегда откатываются "новые" транзакции.

> Но в общем это бессодержательный спор.

В общем, нет. Опять-таки, и теоретически, и на практике в других СУБД это работает. И отмахиваться от проблемы — это какой-то любительский подход. ;)

> Да, проблемы с дедлок детешинов в ПГ есть, но они на мой взгляд

Послушайте... я вот показал ситуацию, когда прогресса не будет. Она понятна? Есть возражения по её практической возможности?
Если да и нет — я утверждаю, что это дефект, просто и очевидно.
И конкретно он вызван "и так сойдёт" подходом ("кто выявил, тот и умрёт") к deadlock resolution.

> Дедлоки не неизбежное зло

Я писал, что какие-то implicit rollback — неизбежное зло.

> вообще говоря не правда

Эээ... что?! Поясните, о чём Вы говорите (кроме нижеописанного). Потому что это (то, что я имел в виду), вообще-то — "базовая" теория.

> Если приложение в состоянии контролировать порядок запроса блокировок

Не приложение, а приложения. Все они, "глобально", должны запрашивать их одинаково во всех ситуациях (и кстати, СУБД тоже должна делать то же самое для своих внутренних блокировок). Поэтому на практике такое не используется, насколько мне известно (или Вы знаете какую-то СУБД без implicit rollbacks в принципе?).

> Дедлоки  не желательно рассматривать как штатную ситуацию, потому как время их обнаружения в Пг достаточно большое

И это ничего не доказывает. Это время обнаружения (разрешения, на самом деле) либо приемлемо (и, при наличии handling, их наличие можно просто игнорировать), либо нет (и тогда стоит заняться avoidance для конкретного случая). И Вы не описали альтернативу — вот есть deadlock, который "не рассматривается, как штатная ситуация" — что делать-то?

> 3. Если же дедлоки возникают крайне редко ...  то тогда можно просто отлавливать ошибку и рестартовать транзакцию.

А если нет, но "неожиданный" deadlock случился — halt and catch fire? ;)

А разве их нет в bind-ах в логах?

Нет...