> Он задал вопрос, ему объяснили, что это нормально Пример Брюса

может быть не самый удачный, но *где* ему отвечают, что поведение нормальное? На самом деле, желание предпринять кое-какие дествия были у Роберта Хааса в сообщении о разделении cancel команды

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

Проблема в том, что деньги теряются незаметно при использовании клиентских либ, которые отменяют запросы по таймауту.
Для сравнения, Oracle Data Guard заявляет от нулевых потерях при нормальном функционировании (доступности) кластера

>> Речь о нулевом (или почти нулевом) RPO при синхронной репликации
Да, почти нулевом.

Сюда не входят потери от Ctrl+C / Сtrl+D

> Да, естественно (и так должно быть! Я к тому, что альтернативы здесь только две, и вторая гораздо хуже, нет?).

про какие альтернативы идёт речь?

> Но чем Вам именно эта ситуация важнее всех прочих, аналогичных ей?

немного не понял, что с чем сравнивают

> Пример Брюса может быть не самый удачный, но *где* ему отвечают, что поведение нормальное? Да вот же (выделение моё)! ——— > 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, хотя на репликах её ещё нет.