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

From Amit Kapila
Subject Re: repeated decoding of prepared transactions
Date
Msg-id CAA4eK1J_ga6zW6BzQtiwEX-1KZMz-YeoEg0Yd3+1hie136mEwQ@mail.gmail.com
Whole thread Raw
In response to Re: repeated decoding of prepared transactions  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sat, Feb 13, 2021 at 10:23 PM Andres Freund <andres@anarazel.de> wrote:
>
> On 2021-02-13 17:37:29 +0100, Petr Jelinek wrote:
>
> > 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, ...).
>

We are already using origins in apply-worker to guarantee that and
with each commit, the origin's lsn location is also WAL-logged. That
helps us to send the start location for a slot after the restart. As
far as I understand this is how it works from the apply-worker side. I
am not sure if I am missing something here?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Default wal_sync_method on FreeBSD
Next
From: Peter Geoghegan
Date:
Subject: Re: 64-bit XIDs in deleted nbtree pages