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
Список 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 по дате отправления: