Re: repeated decoding of prepared transactions - Mailing list pgsql-hackers

From Andres Freund
Subject Re: repeated decoding of prepared transactions
Date
Msg-id 20210213165323.7ri3f5wrgxjrpjum@alap3.anarazel.de
Whole thread Raw
In response to Re: repeated decoding of prepared transactions  (Petr Jelinek <petr.jelinek@enterprisedb.com>)
Responses Re: repeated decoding of prepared transactions
List 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 by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: repeated decoding of prepared transactions
Next
From: "Joel Jacobson"
Date:
Subject: Re: Some regular-expression performance hacking