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

синхронизации
> синхронных реплик, тогда база откроется после фейловера.
Нет, тогда именно эта база не откроется никогда. ;)

Приведите кейс, когда не откроется, с учётом, конечно, что кластер в конце концов соберётся)

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

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"

> Приведите кейс, когда не откроется, с учётом, конечно, что кластер в конце концов соберётся) Именно этот кластер баз PostgreSQL будет уничтожен (или "перемотан" pg_rewind) в случае failover в любом случае, не так ли? > Да, в виду отсутствия такого фукнционала на стороне СУБД Нет, не "в виду отсутствия", а это в принципе не её дело, IMNSHO. > cancel request - игнор, > SIGTERM - рестарт с последующим закрытием соединений, Неплохая "мина" для всякого, кто захотел завершить зависший процесс. :( > statement_timeout - зависит от того как гасится запрос, скорее всего, тоже игнор Понятно. > к чему это??? автофейловер же не потребует вмешательства DBA Я имел в виду случай, когда cancel вызывает shutdown. > Только вот дока не предупреждает от локальных коммитах при Ctrl+C / Ctrl+D, где > нарушается утвеждение о положительном ответе от коммита при полной синхронизации > реплик Предупреждает, и не нарушается. Никто Вам никакого "положительного ответа" не выдаёт в этой ситуации. Если это не так -- это, конечно, bug. Можете показать repro? > тут вопрос с потерей коммитов при фейловере. Ох, сколько раз об этом ещё писать( Да сколько хотите. "Магии" в окружающую реальность это не добавит. :( > При зависании на ожидании сервер всё также отзывчив на изменения > synchronous_standby_names, и возможность прервать зависание при отключении > синхронной репликации - не байка Это мало что поясняет, на самом деле. И я думаю, что необходимость самостоятельного "выкапывания" подробностей из Вашего patch (ещё до review) не добавит ему популярности среди committers. Впрочем, дело Ваше. ;( > Никакой мысли я здесь не вижу, одни эмоции( Знаете что... Вы можете называть факты "эмоциями" сколько Вам угодно. По-моему, Вы не хотите ничего понимать, а хотите только спорить. :( > Недостаточна, поэтому мы и пытаемся её доработать) Вы пытаетесь это сделать неправильным образом. И, по-моему, это оттого, что у Вас вообще неверный подход -- Вы пытаетесь решить не то и не так. > Хорошо, без автоматики, как будете возвращать бывший мастер в кластер Не. Существует. Никакого. Кластера. Сколько можно уже, а?! У Вас просто есть репликация, и больше ничего. > нивелируя потери при фейловере Т.е. — никак! Это *авария*, данные потеряны, если вытащить их не удастся (другими путями) — на том и конец. Предлагаю рассмотреть случай, когда Ваш master просто сгорел. Данные (которые "не доехали" до реплик) были только на нём, game over. > Пока мы только высказываемся, заметьте, А вот некоторые committers уже тоже высказались, я заметил. > патч не отклонили на коммитфесте, Да, пока не отклонили. > он всего лишь в статусе "Need review" Удачи в ожидании reviewers.