> Пример Брюса может быть не самый удачный, но *где*

ему отвечают, что поведение нормальное?
Да вот же (выделение моё)!
———
> This gets to the heart of something I was hoping to discuss. When is
> something committed? You would think it is when the client receives the
> commit message, but Postgres can commit something, and try to inform the
> client but fail to inform, perhaps due to network problems.

This kind of problem can happen even without synchronous replication. I've alluded to this problem in a couple of blog posts I've done on sync rep.

If an application is connected to the database and sends a COMMIT command (or a data-modifying command outside a transaction that will commit implicitly) and the connection is closed before it receives a response, it does not know whether the COMMIT actually happened. It will have to wait until the database is back up and running and then go examine the state of the database with SELECT statements and try to figure out whether the changes it wanted actually got made. Otherwise it doesn't know whether the failure that resulted in a loss of network
connectivity occurred before or after the commit.

I imagine that most applications are way too dumb to do this properly and just report errors to the user and let the user decide what to do
to try to recover. And I imagine that most users are not terribly careful about it and such events cause minor data loss/corruption on a regular basis. But there are also probably some applications where people are really fanatical about it.
———
Т.е. в любом подобном случае (the connection is closed before it receives a response) закомиттилась транзакция или нет — не определено (это, кстати, вообще прямо предписывается ISO SQL, а прямо предписывается оно потому, что это азбука ACID!).
Т.е. если какие-то приложения слишком тупые, чтобы правильно работать с транзакциями в подобных ситуациях — это их проблемы (у них будет minor data loss/corruption on a regular basis)!

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

> Сюда не входят потери от Ctrl+C / Сtrl+D
В том числе, да.

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

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