Re: repeated decoding of prepared transactions
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Markus Wanner <markus.wanner@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>,
Ajin Cherian <itsajin@gmail.com>
Date: 2021-02-12T10:33:11Z
Lists: pgsql-hackers
On Fri, Feb 12, 2021 at 1:10 AM Robert Haas <robertmhaas@gmail.com> wrote: > > On Thu, Feb 11, 2021 at 5:37 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > to explain the exact case to you which is not very apparent. The basic > > idea is that we ship/replay all transactions where commit happens > > after the snapshot has a consistent state (SNAPBUILD_CONSISTENT), see > > atop snapbuild.c for details. Now, for transactions where prepare is > > before snapshot state SNAPBUILD_CONSISTENT and commit prepared is > > after SNAPBUILD_CONSISTENT, we need to send the entire transaction > > including prepare at the commit time. > > This might be a dumb question, but: why? > > Is this because the effects of the prepared transaction might > otherwise be included neither in the initial synchronization of the > data nor in any subsequently decoded transaction, thus leaving the > replica out of sync? > Yes. -- With Regards, Amit Kapila.
Commits
-
Add option to enable two_phase commits via pg_create_logical_replication_slot.
- 19890a064ebf 14.0 landed
-
Avoid repeated decoding of prepared transactions after a restart.
- 8bdb1332eb51 14.0 landed
-
Allow decoding at prepare time in ReorderBuffer.
- a271a1b50e9b 14.0 cited