> после рестарта локальные изменения видны пользователю, а после

фейловера - уже нет. Этот кейс я уже вроде приводил
И надёжно решить его, насколько я вижу, невозможно. Или Вы считаете иначе?

> Поэтому я и предлагаю закрывать соединения к базе
Каким именно образом "закрывать"? Immediate shutdown (по любому "чиху")?
Я почему-то не думаю, что пользователи (включая DBA) этому обрадуются...

> Синхронная репликация (по-хорошему) обещает нулевые потери при цельном кластере
Нет, не обещает. Т.е. реальность такова, что средствами синхронной репликации этого достигнуть во всех без исключения случаях невозможно.
Простой пример — primary crash в процессе ожидания ответа синхронной реплики.
После recovery primary оказывается ровно в той же ситуации (эта транзакция оказывается committed). Что с этим можно сделать?

> и именно к этому мы и стремимся
Да стремитесь, только зачем vanialla PostgreSQL ради этого "ломать"? ;)
Почему бы Вам не сделать extension на эту тему, например?

> что проверка по данным на 100% не работоспособна в кластере даже при синхронной репликации
"Проверка по данным" должна работать всегда, иначе приложения/схемы (с которыми не работает) — просто "косые".

> вступает в дело HA обвязка, либо будет автофейловер
Хорошо, это плюс в такой ситуации. А если не вступает, что дальше будет?

> либо переключение в асинхронный режим мастера без дальнейшего фейловера
Эээ... а технически это как будет реализовано?
Я к тому, что вот "висит" backend, ждёт только ответа реплик... и тут он как-то должен узнать, что надо прекратить это делать, я правильно понял?

> Мы боремся, чтобы эта убиваемость не порождала локальных коммитов, потенциональных на откат в кластере
Да нет никакого "кластера"! Вы его себе вообразили, извините, и потому мечтаете о том, чего нет и не должно быть, мне кажется. :(

> В самом простом случае, DBA выключает (или даже ослабляет) синхронную репликацию через модификацию synchronous_standby_names
В конце концов... у Вас уже есть рабочий, оттестированный patch на эту тему? И хоть один committer, который вообще согласен с этим подходом? ;)

>> после рестарта локальные изменения видны пользователю, а после фейловера - уже нет. Этот кейс я уже вроде приводил И надёжно решить его, насколько я вижу, невозможно. Или Вы считаете иначе? Если закрывать соединения к базе после рестарта до момента синхронизации синхронных реплик, тогда база откроется после фейловера. Тут надо отметить, что открывание базы должно быть после того как соберётся кворум (необходимый набор сихронных реплик с положительными ответами о синхронизации) вокруг нового мастера. И можно будет уже спокойно проверять статус прерванных транзакций, потому как они здесь и далее будут стабильны. >> Поэтому я и предлагаю закрывать соединения к базе Каким именно образом "закрывать"? Immediate shutdown (по любому "чиху")? Выключать узел ни в коем случае не нужно, необходимо, чтобы узел принимал соединения на репликацию и от суперюзера. HA обвяка это может осуществить через манипуляцию с pg_hba.conf, как это делает столон https://github.com/sorintlab/stolon/blob/master/doc/syncrepl.md#handling-postgresql-sync-repl-limits-under-such-circumstances > Я почему-то не думаю, что пользователи (включая DBA) этому обрадуются... Всё это рассчитано на DBA, для которых гораздо большей проблемой становится потеря данных при синхронной репликации >> Синхронная репликация (по-хорошему) обещает нулевые потери при цельном кластере Нет, не обещает. Т.е. реальность такова, что средствами синхронной репликации этого достигнуть во всех без исключения случаях невозможно. В моей схеме потеря будет лишь при краше постгресового кворума > Простой пример — primary crash в процессе ожидания ответа синхронной реплики. После recovery primary оказывается ровно в той же ситуации (эта транзакция оказывается committed). Что с этим можно сделать? см. выше >> и именно к этому мы и стремимся Да стремитесь, только зачем vanialla PostgreSQL ради этого "ломать"? ;) в треде патч предполагает опциональность реакции на Ctrl+C / Сtrl+D > Почему бы Вам не сделать extension на эту тему, например? К сожаления со стороны экстеншна не подобраться к логике ожидания синхронного коммита

>> вступает в дело HA обвязка, либо будет автофейловер Хорошо, это плюс в такой ситуации. А если не вступает, что дальше будет? тут либо никаких фейлов нет и синхронный коммит рано или поздно завершится, либо HA движок не детектирует фейл, что требует его доработки. В любом случае, синхронную репликацию можно ослабить или отключить вручную и всё пойдёт далее >> либо переключение в асинхронный режим мастера без дальнейшего фейловера Эээ... а технически это как будет реализовано? Я к тому, что вот "висит" backend, ждёт только ответа реплик... и тут он как-то должен узнать, что надо прекратить это делать, я правильно понял? Это решает HA движок, и только он. По таймауту фейла синхронной реплики, если никакой замены ей нет, то кластер переключается в ассинхронный режим при условии, что кворум DCS всё ещё на стороне мастера. Это функциональность аналогична Max Availability режиму в Oracle Data Guard >> Мы боремся, чтобы эта убиваемость не порождала локальных коммитов, потенциональных на откат в кластере Да нет никакого "кластера"! Вы его себе вообразили, извините, и потому мечтаете о том, чего нет и не должно быть, мне кажется. :( Сформулируйте конкретно вашу мысль. Здесь описываемая проблема касается только кластерной инсталляции "мастер-реплика". Особенно сюда попадают кластера, где есть автоматика - на промоут узла и демоут с откатом неотреплицированных изменений (например, через pg_rewind). Говоря про "локальные коммиты, потенциальных на откат в кластере", я имею в виду откат изменений при демоуте узла, т.е. коммит мог подтвердиться на старом мастере, но после фейловера и pg_rewind он окончательно теряется > В конце концов... у Вас уже есть рабочий, оттестированный patch на эту тему? Да, на коммитфесте > И хоть один committer, который вообще согласен с этим подходом? ;) К консенсусу мы пока не пришли, но наша сторона практически полностью высказалась по этой проблеме, ответ за хакерами)