Re: repeated decoding of prepared transactions

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: repeated decoding of prepared transactions
Дата
Msg-id 20210213165323.7ri3f5wrgxjrpjum@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: repeated decoding of prepared transactions  (Petr Jelinek <petr.jelinek@enterprisedb.com>)
Ответы Re: repeated decoding of prepared transactions  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
Hi,

On 2021-02-13 17:37:29 +0100, Petr Jelinek wrote:
> Agreed, if we relied purely on flush location of a slot, there would
> be no need for origins to track the lsn.

And we would be latency bound replicating transactions, which'd not be
fun for single-insert ones for example...


> AFAIK this is exactly why origins are Wal logged along with
> transaction, it allows us to guarantee never getting anything that has
> beed durably written.

I think you'd need something like origins in that case, because
something could still go wrong before the other side has received the
flush (network disconnect, primary crash, ...).

Greetings,

Andres Freund



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

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: repeated decoding of prepared transactions
Следующее
От: "Joel Jacobson"
Дата:
Сообщение: Re: Some regular-expression performance hacking