Мы наблюдаем некоторые поведения / ошибки в некоторых наших рабочих процессах, связанные с согласованностью и видимостью транзакции записи Postgres, за которой следует чтение. Один из наших разработчиков предложил объяснение, но я не смог найти никаких результатов поиска, документирующих предлагаемое обоснование.
Для одного хоста Postgres 10.3 выполняются следующие операции:
- ClientA выполняет успешную транзакцию записи
- После COMMIT отправляется внешнее уведомление
- ClientB реагирует на внешнее уведомление и выполняет чтение только для того, чтобы обнаружить, что изменения транзакции UPDATE не видны
Было предложено объяснение, что два клиентских соединения postgres в разных потоках не имеют гарантированного снимка представления и могут не сразу наблюдать обновление транзакции записи после фиксации. Но из того, что я прочитал, я ожидал, что после успешного выполнения команды COMMIT операция чтения, а затем запуск в ответ, должны увидеть результаты этой записи.
Мой конкретный c вопрос: Учитывая два клиента базы данных соединения в разных потоках, возможно ли состояние состязания с одним клиентом, просматривающим эффекты транзакции записи ПОСЛЕ того, как другой клиент совершил? (без перекрывающихся транзакций).
Каждый фрагмент документации, который я нашел до сих пор, касается только вопросов о перекрывающихся / параллельных транзакциях и разделах MVCC / изоляции транзакций. Ничего о синхронизированной последовательной операции между двумя различными клиентскими подключениями.
Редактировать: некоторые дополнительные сведения о конфигурации. ClientA и ClientB будут разными потоками, получающими доступ к postgres через пул соединений. Оба клиента могут находиться в одном и том же пуле соединений на одном сервере приложений, или это могут быть ClientA / ApplicationA и ClientB / ApplicationB. Когда ClientB реагирует, он обращается к существующему пулу соединений с сервером приложений, чтобы выполнить новое чтение.