> Т.е. в любом подобном случае (the connection is closed

before it receives a response) закомиттилась транзакция или нет — не определено (это, кстати, вообще прямо предписывается ISO SQL, а прямо предписывается оно потому, что это азбука ACID!).

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

> Так не используйте эти "либы"

в последнем сообщении Михаил Николаев приводит ссылки, насколько часто в java софте используется функция отмена запроса. Это заставляет задуматься, насколько немейнстримовый вариант - отказаться от отмены запросов на стороне приложения.
Потом никто не отменял Ctrl+C / Ctrl+D со стороны DBA.

> (или обучите тех, кто писал этот кривой код и использовал такой подход, при котором нельзя только по данным узнать, выполнилась ли данная транзакция или нет — и это, опять-таки, основы!).

А как в таком случае однозначно узнать, закоммичена транзакция в кластере или нет?)

> Да про любой transaction termination в подобной ситуации (транзакция прервалась по любой причине после making it durable, но до репликации — она считается committed).
Самое простое — master "упал" после этой фазы commit, до отправки WAL на реплики — когда он поднимется, эта транзакция на нём committed, хотя на репликах её ещё нет.

Я уже писал, что такой кейс поднятия экземпляра можно перехватить в HA движках и выбрать один из двух вариантов:
либо оставить мастер как есть, закрыть соединения, чтобы локально закоммиченные данные не были видны, и ждать, пока синхронные реплики не синхронизируются,
либо осуществить фейловер на синхронную реплику и далее вокруг неё строить кластер

> допустим, после рестарта мастера до автофейловера изменения видны пользователю, потом после автофейловера он их потерял Конечно. Опять-таки, поэтому (RPO): "Да, почти нулевом." > в последнем сообщении Михаил Николаев приводит ссылки Не открывал (и не буду, извините). Но я вполне уверен, что приложений, которые "криво" работают с СУБД, гораздо больше, чем нормальных, и без каких-либо ссылок. ;( > А как в таком случае однозначно узнать, закоммичена транзакция в кластере или нет?) Да по данным же! Ещё раз, если кто-то моделирует так, что только по данным нельзя узнать, была ли какая-то транзакция committed или нет (точнее, надо ли её повторять или нет) — допускать этого "кого-то" к работе с важными данными не стоит. Вы же понимаете, что без всяких там репликаций, в совершенно обычных ситуациях, всегда существует ровно та же проблема? > чтобы локально закоммиченные данные не были видны, и ждать, пока синхронные реплики не синхронизируются, Хмм.. а это ещё зачем? > либо осуществить фейловер на синхронную реплику И в этом случае нужно чётко понимать, что какие-то данные могли быть потеряны, и сделать с этим ничего нельзя. Т.е. к такой ситуации всегда нужно относиться, как к аварийной, и что-то проверять / решать (что именно, зависит от конкретной базы / приложений).