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

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

> Тут надо отметить, что открывание базы должно быть после того <skip>
Такими "сложностями" должна заниматься "HA-обвязка", IMNSHO.

> Выключать узел ни в коем случае не нужно, необходимо, чтобы узел принимал
> соединения на репликацию и от суперюзера. HA обвяка это может осуществить через
> манипуляцию с pg_hba.conf, как это делает столон
А что делать тогда, я не понял? Вот послал кто-то cancel request / SIGTERM / сработал statement_timeout в какой-то сессии, которая ждёт ответа от синхронной реплики. Что конкретно должно происходить?

> Всё это рассчитано на DBA, для которых гораздо большей проблемой становится потеря данных при синхронной репликации
А то, что кто угодно может "срубить" primary, для DBA не проблема? ;)
И ещё раз, потеря данных при этих ситуациях нормальна, об этом прямо предупреждает документация (с "разжёвыванием")!
Т.е. любой failover — аварийная ситуация, относиться к нему как-то иначе — вот это проблема.

> В моей схеме потеря будет лишь при краше постгресового кворума
Может, да, а может — нет. Я "Вашей схемы" не видел (возможность потери данных может зависеть от каждой маленькой детали "схемы", я вот о чём).

> в треде патч предполагает опциональность реакции на Ctrl+C / Сtrl+D
Я даже пролистал его, но не вчитывался. Вы его тестировали? ;)
Если да -- расскажите на реакции при разных настройках нового GUC (я, вроде бы, не видел в thread в -hackers подробного описания).

> К сожаления со стороны экстеншна не подобраться к логике ожидания синхронного коммита
А не лучше ли нацелиться на то, чтоб можно было подобраться?
Т.е. написать patch для добавления соответствующего hook.

> Сформулируйте конкретно вашу мысль.
Куда уже конкретнее? ;(

> Здесь описываемая проблема касается только кластерной инсталляции "мастер-реплика".
Такой вещи, как "кластерной инсталляции" (только из-за того, что Вы используете синхронную репликацию, она не появляется) не существует, Вы её себе вообразили! Синхронная репликация не предназначена и недостаточна для реализации "кластерных инсталляций".

> Особенно сюда попадают кластера, где есть автоматика - на промоут узла и демоут с откатом неотреплицированных изменений (например, через pg_rewind).
И кто им виноват, что у них есть такая "автоматика", а? ;)

> К консенсусу мы пока не пришли, но наша сторона практически полностью высказалась по этой проблеме, ответ за хакерами)
"Ответ за хакерами", насколько я вижу, пока "минус 3!" от основных contributors/committers... или я что-то упустил?

>> Если закрывать соединения к базе после рестарта до момента синхронизации > синхронных реплик, тогда база откроется после фейловера. Нет, тогда именно эта база не откроется никогда. ;) Приведите кейс, когда не откроется, с учётом, конечно, что кластер в конце концов соберётся) > И всё равно я не понимаю (с учётом написанного ниже), как это будет технически выглядеть. HA агенты, помимо всего прочего, являются оркестраторами постгрес-экземпляров. Они как родительские процессы могут перехватить падение постгреса и они же могут запустить его с нужными параметрами, в т.ч., при промоуте предварительно менять pg_hba.conf >> Тут надо отметить, что открывание базы должно быть после того <skip> Такими "сложностями" должна заниматься "HA-обвязка", IMNSHO. Да, в виду отсутствия такого фукнционала на стороне СУБД > А что делать тогда, я не понял? Вот послал кто-то cancel request / SIGTERM / сработал statement_timeout в какой-то сессии, которая ждёт ответа от синхронной реплики. Что конкретно должно происходить? cancel request - игнор, SIGTERM - рестарт с последующим закрытием соединений, statement_timeout - зависит от того как гасится запрос, скорее всего, тоже игнор > А то, что кто угодно может "срубить" primary, для DBA не проблема? ;) к чему это??? автофейловер же не потребует вмешательства DBA > И ещё раз, потеря данных при этих ситуациях нормальна, об этом прямо предупреждает документация (с "разжёвыванием")! Только вот дока не предупреждает от локальных коммитах при Ctrl+C / Ctrl+D, где нарушается утвеждение о положительном ответе от коммита при полной синхронизации реплик > Т.е. любой failover — аварийная ситуация, относиться к нему как-то иначе — вот это проблема. тут вопрос с потерей коммитов при фейловере. Ох, сколько раз об этом ещё писать( >> в треде патч предполагает опциональность реакции на Ctrl+C / Сtrl+D Я даже пролистал его, но не вчитывался. Вы его тестировали? ;) Не только тестировал, но и правил > Если да -- расскажите на реакции при разных настройках нового GUC (я, вроде бы, не видел в thread в -hackers подробного описания). При зависании на ожидании сервер всё также отзывчив на изменения synchronous_standby_names, и возможность прервать зависание при отключении синхронной репликации - не байка >А не лучше ли нацелиться на то, чтоб можно было подобраться? Т.е. написать patch для добавления соответствующего hook. Можно, но в ядре наш патч выглядит логичнее: хуки должны быть более-менее юзабельны и для других кейсов >> Сформулируйте конкретно вашу мысль. Куда уже конкретнее? ;( > Здесь описываемая проблема касается только кластерной инсталляции "мастер-реплика". Такой вещи, как "кластерной инсталляции" (только из-за того, что Вы используете синхронную репликацию, она не появляется) не существует, Вы её себе вообразили! Никакой мысли я здесь не вижу, одни эмоции( > Синхронная репликация не предназначена и недостаточна для реализации "кластерных инсталляций". Недостаточна, поэтому мы и пытаемся её доработать) >> Особенно сюда попадают кластера, где есть автоматика - на промоут узла и демоут с откатом неотреплицированных изменений (например, через pg_rewind). И кто им виноват, что у них есть такая "автоматика", а? ;) Хорошо, без автоматики, как будете возвращать бывший мастер в кластер, нивелируя потери при фейловере > "Ответ за хакерами", насколько я вижу, пока "минус 3!" от основных contributors/committers... или я что-то упустил? Пока мы только высказываемся, заметьте, патч не отклонили на коммитфесте, он всего лишь в статусе "Need review"