Re: [HACKERS] logical decoding of two-phase transactions

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: Ajin Cherian <itsajin(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Date: 2021-03-03 12:21:10
Message-ID: CAA4eK1KhfzCYDmv17beC6wOX_5pL-MBNYBpMiLgxrdgF1yBYng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 27, 2021 at 8:10 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> Please find attached the latest patch set v45*
>
> Differences from v44*:
>
> * Rebased to HEAD
>
> * Addressed some feedback comments for the 0007 ("empty prepare") patch.
>
> [ak1] #1 - TODO
> [ak1] #2 - Fixed. Removed #if 0 debugging
> [ak1] #3 - TODO
> [ak1] #4 - Fixed. Now BEGIN_PREPARE and PREPARE msgs are spooled. The
> lsns are obtained from them.
>

@@ -774,6 +891,38 @@ apply_handle_prepare(StringInfo s)
{
LogicalRepPreparedTxnData prepare_data;

+ /*
+ * If we were using a psf spoolfile, then write the PREPARE as the final
+ * message. This prepare information will be used at commit_prepared time.
+ */
+ if (psf_fd)
+ {
+ /* Write the PREPARE info to the psf file. */
+ Assert(prepare_spoolfile_handler(LOGICAL_REP_MSG_PREPARE, s));

Why writing prepare is under Assert?

Similarly, the commit_prepared code as below still does prepare:
+ /*
+ * 2. mark as PREPARED (use prepare_data info from the psf file)
+ */
+
+ /*
+ * BeginTransactionBlock is necessary to balance the
+ * EndTransactionBlock called within the PrepareTransactionBlock
+ * below.
+ */
+ BeginTransactionBlock();
+ CommitTransactionCommand();
+
+ /*
+ * Update origin state so we can restart streaming from correct
+ * position in case of crash.
+ */
+ replorigin_session_origin_lsn = pdata.end_lsn;
+ replorigin_session_origin_timestamp = pdata.preparetime;
+
+ PrepareTransactionBlock(pdata.gid);
+ CommitTransactionCommand();
+ pgstat_report_stat(false);
+
+ store_flush_position(pdata.end_lsn);

This should automatically happen via apply_handle_prepare if we write
it to spool file.

* prepare_spoolfile_replay_messages() shouldn't handle special cases
for BEGIN_PREPARE and PREPARE messages. Those should be handled by
there corresponding apply_handle_* functions. Before processing the
messages remote_final_lsn needs to be set as commit_prepared's
commit_lsn (aka prepare_data.prepare_lsn)

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2021-03-03 12:21:31 Re: Why OR-clauses not getting copied into baserestrictinfo of another table whose columns are in the same EquivalenceClass?
Previous Message Greg Nancarrow 2021-03-03 12:20:22 Re: Parallel INSERT (INTO ... SELECT ...)