Плюсую

наброшу еще...
сделал пару небольших тестов, каждый может воспроизвести у себя.
На входе относительно большая pgbench база, чтобы апдейт всех строк в pgbench_accounts не прошел мгновенно )))

1. a. Запускаем просто psql -c "update pgbench_accounts set abalance = 1"
b. завершаем psql через kill -9
с. update продолжает работать, после завершения abalance всех строк = 1.

2. a. создаем файл "test.pgbench" в котором оборачиваем тот же самый update, но значение баланса например = 2.
b. запускаем pgbench -t 1 -f test.pgbench - то есть хотим чтобы pgbench выполнил одну транзакцию.
с. завершаем pgbench через kill -9
d. запрос продолжает работать, после завершения транзакция откатывается, все балансы != 2

такие дела.

1. Автокоммит. Ожидаемо.

2. Значит ли это, что pgbanch явно открыл транзакцию?
Иначе результат должен был быть одинаковый.

блин в в верхнем сообщении потерял про "оборачиваем в транзакцию" 😂

Ты это специально)

)))

Пока транзакция не закоммичена на мастере, т.е. пока в WAL-е у него не оказалось commit record-а, она не может быть закоммичена на реплике. Соответственно не возможна ситуация, когда всё упало, после чего мы рестартовали и выяснили, что реплики убежали вперёд мастера.

Вы про synchronous commit = on.
А если remote_apply?

да всё равно. Это не важно.
Последовательность такая:
1. Сначала транзакция полностью попадает в WAL
2. Потом WAL sender рассылает её по репликам
3. Дальше в зависимости от политики репликации мы ждём пока реплика либо не зафлашит полученные изменения в свой WAL, либо их применит

Никогда не возможна ситуация когда в WAL-ах репик оказалось больше, чем в WAL-ах мастера. Им там просто неоткуда взяться.

Если на шаге 3 произошло аврийное завершение постгреса или даже бэкенда, то транзакция на мастера будет закоммиченной, а на репликах - под вопросом.

ну тогда документация врёт вот тут: https://www.postgresql.org/docs/current/runtime-config-wal.html
> When set to remote_apply, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and applied it, so that it has become visible to queries on the standby(s), and also written to durable storage on the standbys.

нет - здесь всё правда и не противоречит тому, что я сказал

ну как же не противоречит, когда транзакция была записана локально remote_write и применена remote_apply и уже видна.
если мы активируем реплику — она останется видна, в отличии от мастера

1. Статус транзакции на синк реплике завершён,
2. Мастер ещё не получил ответ от синк, следовательно и для клиента транзакция ещё не зафиксирована.
3. Мастер сгорел, утанул, ушёл пить пиво...
4. В общем failover и мы переключились на синк

Что же думает клиент?
Для него не было фиксации, был лишь failover.

И если на стороне приложения нет никаких перепроверок...

"commits will wait until" означает, что клиенту не вернётся подтверждение коммита до тех пора пока... далее по тексту. И другие транзакции до этих пор эту видят не будут (локи не отпушены, в clog транзакция не помечена как закоммиченая). Но в WAL-е транзакция полностью закоммичена. И если в этот момент происходит сбой, то траназакция на мастера становится де факто закоммичена.

в документации чётко сказано, что запросы на репликах увидят эту транзакцию

нет, там сказано не это.

там именно это и сказано!

Со значением remote_apply фиксирование завершается только после получения ответов от текущих синхронных ведомых серверов, говорящих, что они получили запись о фиксировании транзакции, сохранили её в надёжном хранилище, а также применили транзакцию, так что она стала видна для запросов на этих серверах

т.е. на синхронных репликах транзакция видна для запросов!

> Со значением remote_apply фиксирование завершается только после получения ответов от текущих синхронных ведомых серверов, говорящих, что они получили запись о фиксировании транзакции, сохранили её в надёжном хранилище, а также применили транзакцию, так что она стала видна для запросов на этих серверах

и вот только после этого мастер отвечает клиенту что "я все, закомитил твою транзакцию" - мне кажется Константин об этом, не?

если на синхронной реплике применилось, а масетр “ушёл”, то получается:
- клиенту подтверждения не было, он вправе считать, что был откат
- после активации синхронной реплики транзакция становиться видна

я согласен, что на мастере WAL был записан и буде проигран. но только если мы промотим реплику – получается расхождение между мнением клиента и состоянием базы