Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
Дата
Msg-id 20220805.114916.994654810780821553.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Список pgsql-hackers
At Tue, 26 Apr 2022 08:26:59 +0200, Laurenz Albe <laurenz.albe@cybertec.at> wrote in 
> While this may mitigate the problem, I don't think it will deal with
> all the cases which could cause a transaction to end up committed locally,
> but not on the synchronous standby.  I think that only using the full
> power of two-phase commit can make this bulletproof.
> 
> Is it worth adding additional complexity that is not a complete solution?

I would agree to this. Likewise 2PC, whatever we do to make it
perfect, we're left with unresolvable problems at least for now.

Doesn't it meet your requirements if we have a means to know the last
transaction on the current session is locally committed or aborted?

We are already internally managing last committed LSN. I think we can
do the same thing about transaction abort and last inserted LSN and we
can expose them any way. This is way simpler than the (maybe)
uncompletable attempt to fill up the deep gap.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Introduce wait_for_subscription_sync for TAP tests