Ну без comment он не те данные получит, поэтому...
Ладно буду молчать.

Я, наверное, пропустил часть обсуждения, но:

> Реакция внешнего инструмента кластеризации на самоизоляцию далеко не мгновенная.

Ну и что? При "самоизоляции" (если не считать bugs) и commit-а не будет, т.е. primary просто "встанет", да и всё.

> Тем более, мастер коммитит в clog независимо от slaves даже при синхронной реплике.

Хмм... о чём именно речь (я как-то сходу не вспомнил)? И, тем не менее, см. выше.

Но, вообще, failover на любую реплику — это disaster, т.е. не стоит его рассматривать иначе, IMHO.

primary попишет в clog, потом встанет, master уйдёт на другой инстанс, и там этих транзакций не будет. Потом старый друг воспрянет, сделает rewind, а данные — поминай, как звали.

primary попишет в clog, потом встанет, master уйдёт на другой инстанс, и там этих транзакций не будет. Потом старый друг воспрянет, сделает rewind, а данные — поминай, как звали.

Оценка это не то на что нужно смотреть в первую очередь

А кому-то ответили, что они committed? ;)
Ведь нет же — значит, проблемы нет.

Действительно. Только один момент, данные сначала упали на реплику и не успели зафиксировать на мастере, как тогда)

Так же.
Любая прерванная в COMMIT транзакция должна клиентскими приложениями (и теми, кто их пишет) считаться завершённой с неопределённым результатом, и если они "думают" иначе — это, опять-таки, их проблемы.
На практике это означает, что завершение транзакции должно определяться по данным.
Эта проблема всегда есть (реплика тут ни при чём), и тому, кто написал приложение иначе, стоит исправить в нём подобные ошибки.

не, минимальные настройки не на тот порт сажали

Более развёрнуто желательно. В каких портах запутались при настройке?