>> вступает в дело HA обвязка, либо будет автофейловер Хорошо,

это плюс в такой ситуации. А если не вступает, что дальше будет?

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

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

Это решает HA движок, и только он. По таймауту фейла синхронной реплики, если никакой замены ей нет, то кластер переключается в ассинхронный режим при условии, что кворум DCS всё ещё на стороне мастера. Это функциональность аналогична Max Availability режиму в Oracle Data Guard

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

Сформулируйте конкретно вашу мысль. Здесь описываемая проблема касается только кластерной инсталляции "мастер-реплика". Особенно сюда попадают кластера, где есть автоматика - на промоут узла и демоут с откатом неотреплицированных изменений (например, через pg_rewind). Говоря про "локальные коммиты, потенциальных на откат в кластере", я имею в виду откат изменений при демоуте узла, т.е. коммит мог подтвердиться на старом мастере, но после фейловера и pg_rewind он окончательно теряется

> В конце концов... у Вас уже есть рабочий, оттестированный patch на эту тему?

Да, на коммитфесте

> И хоть один committer, который вообще согласен с этим подходом? ;)

К консенсусу мы пока не пришли, но наша сторона практически полностью высказалась по этой проблеме, ответ за хакерами)

Повторите, пожалуйста, что вы планируете сделать, когда произойдёт рассоединение мастера с репликой? Вы планируете разорвать соединения клиентов у мастера? Мастер вначале должен удостовериться в том, что реплики приняли изменения, и только потом у себя принять?

> Если закрывать соединения к базе после рестарта до момента синхронизации > синхронных реплик, тогда база откроется после фейловера. Нет, тогда именно эта база не откроется никогда. ;) И всё равно я не понимаю (с учётом написанного ниже), как это будет технически выглядеть. > Тут надо отметить, что открывание базы должно быть после того <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... или я что-то упустил?