Re: repeated decoding of prepared transactions

>
> On 13 Feb 2021, at 17:32, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2021-02-10 08:02:17 +0530, Amit Kapila wrote:
>> On Wed, Feb 10, 2021 at 12:08 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>
>> If by successfully confirmed, you mean that once the subscriber node
>> has received, it won't be sent again then as far as I know that is not
>> true. We rely on the flush location sent by the subscriber to advance
>> the decoding locations. We update the flush locations after we apply
>> the transaction's commit successfully. Also, after the restart, we use
>> the replication origin's last flush location as a point from where we
>> need the transactions and the origin's progress is updated at commit
>> time.
>
> That's not quite right. Yes, the flush location isn't guaranteed to be
> updated at that point, but a replication client will send the last
> location they've received and successfully processed, and that has to
> *guarantee* that they won't receive anything twice, or miss
> something. Otherwise you've broken the protocol.
>

Agreed, if we relied purely on flush location of a slot, there would be no need for origins to track the lsn. 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.

—
Petr