Re: repeated decoding of prepared transactions

Hi,

On 2021-02-22 14:29:09 +0530, Amit Kapila wrote:
> On Mon, Feb 22, 2021 at 9:39 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > What I am proposing is to instead track the point at which the slot
> > gained consistency - a simple LSN. That way you can change the above
> > logic to instead be
> >
> > if (txn->final_lsn > snapshot_was_exported_at_lsn)
> > ReorderBufferReplay();
> > else
> > ...
> >
>
> With this if the prepare is prior to consistent_snapshot
> (snapshot_was_exported_at_lsn)) and commit prepared is after then we
> won't send the prepare and data. Won't we need to send such prepares?
> If the condition is other way (if (txn->final_lsn <
> snapshot_was_exported_at_lsn)) then we would send such prepares?

Yea, I inverted the condition...

> Just to clarify, after the initial copy, say when we start/restart the
> streaming and we picked the serialized snapshot of some other
> WALSender, we don't need to use snapshot_was_exported_at_lsn
> corresponding to the serialized snapshot of some other slot?

Correct.

> Yeah, we need to probably store this new point as slot's persistent information.

Should be fine I think...

Greetings,

Andres Freund