Re: repeated decoding of prepared transactions

On Tue, Feb 23, 2021 at 8:54 PM Amit Kapila <amit.kapila16@gmail.com> wrote:

> 1. With respect to SQL APIs, currently 'two-phase-commit' is a plugin
> option so it is possible that the first time when it gets changes
> (pg_logical_slot_get_changes) *without* 2PC enabled it will not get
> the prepared even though prepare is after consistent snapshot. Now
> next time during getting changes (pg_logical_slot_get_changes) if the
> 2PC option is enabled it will skip prepare because by that time
> start_decoding_at has been moved. So the user will only get commit
> prepared as shown in the example in the email above [2]. I think it
> might be better to allow enable/disable of 2PC only at create_slot
> time. Markus, Ajin, and I seem to be in agreement on this point. I
> think the same will be true for subscriber-side solution as well.
>

Attaching a patch which avoids repeated decoding of prepares using the
approach suggest by Andres. Added snapshot_was_exported_at_lsn;
fields in ReplicationSlotPersistentData and SnapBuild which now stores
the LSN at which the slot snapshot is exported the time it is created.
This patch also modifies the API pg_create_logical_replication_slot()
to take an extra parameter to enable two-phase commits
and disables pg_logical_slot_get_changes() from enabling two-phase.
I plan to split this into two patches next. But do review and let me
know if you have any comments.

regards,
Ajin