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

On Thu, Feb 25, 2021 at 12:32 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> Please find attached the latest patch set v43*
>
> Differences from v42*
>
> - Rebased to HEAD as @ today
>
> - Added new patch 0006 "Tablesync early exit" as discussed here [1]
>

I feel we can start a separate thread for this as it can be done
independently unless there are reasons for not doing so.

> - Added new patch 0007 "Fix apply worker prepare" as discussed here [2]
>

Few comments on v43-0007-Fix-apply-worker-empty-prepare:
================================================
1. The patch v43-0007-Fix-apply-worker-empty-prepare should be fourth
patch in series, immediately after the main-apply worker patch.
2.
apply_handle_begin_prepare
{
..
+#if 0
+ || true /* XXX - Add this line to force psf (for easier debugging) */
+#endif

Please remove such debugging hacks.

3.
+ * [Note: this is mostly copied code from apply_spooled_messages function]
+ */
+static int
+prepare_spoolfile_replay_messages(char *path, XLogRecPtr lsn)

I think we can try to unify the code in this function and
apply_spooled_messages. Basically, if we pass the sharedfileset handle
to apply_spooled_messages, then it should be possible to unify these
two functions.

4.
@@ -788,6 +897,27 @@ apply_handle_prepare(StringInfo s)
return;
}

+ if (psf_fd)
+ {
+ /*
+ * The psf_fd is meaningful only between begin_prepare and prepared.
+ * So close it now. If we had been writing any messages to the psf_fd
+ * (the spoolfile) then those will be applied later during
+ * handle_commit_prepared.
+ */
+ prepare_spoolfile_close();
+
+ /*
+ * And end the transaction that was created by begin_prepare for
+ * working with the psf buffiles.
+ */
+ Assert(IsTransactionState());
+ CommitTransactionCommand();
+
+ in_remote_transaction = false;
+ return;
+ }

Don't we need to write prepare to the spool file as well? Because, if
we do that then I think you don't need special handling in
apply_handle_commit_prepared where you are preparing the transaction
after replaying the messages from the spool file. I think in
apply_handle_commit_prepared while doing prepare, you have used
commit's lsn which is wrong and that will also be solved if you do
what I am suggesting.

5. You need to write/sync the spool file at prepare time because after
restart between prepare and commit prepared the changes can be lost
and won't be resent by the publisher assuming there are commits of
other transactions between prepare and commit prepared. For the same
reason, I am not sure if we can just rely on the in-memory hash table
for it (prepare_spoolfile_exists). Sure, if it exists and there is no
restart then it would be cheap to check in the hash table but I don't
think it is guaranteed.

--
With Regards,
Amit Kapila.