Horton

Re: repeated decoding of prepared transactions

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: Markus Wanner <markus.wanner@enterprisedb.com>
Cc: Ajin Cherian <itsajin@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, simon.riggs@enterprisedb.com, Andres Freund <andres@anarazel.de>, Petr Jelinek <petr.jelinek@enterprisedb.com>
Date: 2021-02-20T03:38:03Z
Lists: pgsql-hackers 
On Fri, Feb 19, 2021 at 8:23 PM Markus Wanner
<markus.wanner@enterprisedb.com> wrote:
>
> With that line of thinking, the point in time (or in WAL) of the COMMIT
> PREPARED does not matter at all to reason about the decoding of the
> PREPARE operation.  Instead, there are only exactly two cases to consider:
>
> a) the PREPARE happened before the start_decoding_at LSN and must not be
> decoded. (But the effects of the PREPARE must then be included in the
> initial synchronization. If that's not supported, the output plugin
> should not enable two-phase commit.)
>

I see a problem with this assumption. During the initial
synchronization, this transaction won't be visible to snapshot and we
won't copy it. Then later if we won't decode and send it then the
replica will be out of sync. Such a problem won't happen with Ajin's
patch.

-- 
With Regards,
Amit Kapila.

Commits

  1. Add option to enable two_phase commits via pg_create_logical_replication_slot.

  2. Avoid repeated decoding of prepared transactions after a restart.

  3. Allow decoding at prepare time in ReorderBuffer.