>> В это самое "почти", я полагаю, не должны входить

потери после рестарта экземпляра
Предложите хоть одно реалистичное решение. Хотя... какие конкретно потери Вы имеете в виду?

при том же нетсплите, когда после рестарта локальные изменения видны пользователю, а после фейловера - уже нет. Этот кейс я уже вроде приводил

> В норме после рестарта primary изменения "доедут" на реплики — никаких потерь.

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

> > Выше я описал случай, как локально закоммиченные *данные* могут соврать о статусе транзакции в кластере
Синхронная репликация не обещает Вам никаких "статусов транзакции в кластере" (и даже никакого "кластера" в ней нет), она вообще не для этого.

Синхронная репликация (по-хорошему) обещает нулевые потери при цельном кластере и именно к этому мы и стремимся

>> эта проблема схожа, но не столь критична, т.к. есть способы её разрулить
Вот почему бы и не использовать их и при репликации (т.е. в чём существенные отличия — я их не вижу)?

ну писал же выше, что проверка по данным на 100% не работоспособна в кластере даже при синхронной репликации

> Хорошо, вот игнорирует транзакция cancellations, пусть даже игнорирует statement_timeout и висит (ждёт ответа с реплики, которого, допустим, не будет).
Дальше-то что?

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

> Она вообще "неубиваемая", получается (это что, действительно хорошо, Вы считаете)?

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

> А далее, допустим, за ней другие встанут в очередь (особенно "приятно", когда они read only), и вот DBA наблюдает такую картину и делает... что?

В самом простом случае, DBA выключает (или даже ослабляет) синхронную репликацию через модификацию synchronous_standby_names, понимая что именно из-за этого произошло такое зависание

> после рестарта локальные изменения видны пользователю, а после фейловера - уже нет. Этот кейс я уже вроде приводил И надёжно решить его, насколько я вижу, невозможно. Или Вы считаете иначе? > Поэтому я и предлагаю закрывать соединения к базе Каким именно образом "закрывать"? Immediate shutdown (по любому "чиху")? Я почему-то не думаю, что пользователи (включая DBA) этому обрадуются... > Синхронная репликация (по-хорошему) обещает нулевые потери при цельном кластере Нет, не обещает. Т.е. реальность такова, что средствами синхронной репликации этого достигнуть во всех без исключения случаях невозможно. Простой пример — primary crash в процессе ожидания ответа синхронной реплики. После recovery primary оказывается ровно в той же ситуации (эта транзакция оказывается committed). Что с этим можно сделать? > и именно к этому мы и стремимся Да стремитесь, только зачем vanialla PostgreSQL ради этого "ломать"? ;) Почему бы Вам не сделать extension на эту тему, например? > что проверка по данным на 100% не работоспособна в кластере даже при синхронной репликации "Проверка по данным" должна работать всегда, иначе приложения/схемы (с которыми не работает) — просто "косые". > вступает в дело HA обвязка, либо будет автофейловер Хорошо, это плюс в такой ситуации. А если не вступает, что дальше будет? > либо переключение в асинхронный режим мастера без дальнейшего фейловера Эээ... а технически это как будет реализовано? Я к тому, что вот "висит" backend, ждёт только ответа реплик... и тут он как-то должен узнать, что надо прекратить это делать, я правильно понял? > Мы боремся, чтобы эта убиваемость не порождала локальных коммитов, потенциональных на откат в кластере Да нет никакого "кластера"! Вы его себе вообразили, извините, и потому мечтаете о том, чего нет и не должно быть, мне кажется. :( > В самом простом случае, DBA выключает (или даже ослабляет) синхронную репликацию через модификацию synchronous_standby_names В конце концов... у Вас уже есть рабочий, оттестированный patch на эту тему? И хоть один committer, который вообще согласен с этим подходом? ;)