Horton

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

Ajin Cherian <itsajin@gmail.com>

View thread View on postgr.es
From: Ajin Cherian <itsajin@gmail.com>
To: Peter Smith <smithpb2250@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-10-29T10:36:01Z
Lists: pgsql-hackers

Attachments

On Thu, Oct 29, 2020 at 11:48 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> Hi Ajin.
>
> Looking at v13 patches again I found a couple more review comments:
>
> ===
>
> (1) COMMENT
> File: src/backend/replication/logical/proto.c
> Function: logicalrep_write_prepare
> + if (rbtxn_commit_prepared(txn))
> + flags = LOGICALREP_IS_COMMIT_PREPARED;
> + else if (rbtxn_rollback_prepared(txn))
> + flags = LOGICALREP_IS_ROLLBACK_PREPARED;
> + else
> + flags = LOGICALREP_IS_PREPARE;
> +
> + /* Make sure exactly one of the expected flags is set. */
> + if (!PrepareFlagsAreValid(flags))
> + elog(ERROR, "unrecognized flags %u in prepare message", flags);
>
> Since those flags are directly assigned, I think the subsequent if
> (!PrepareFlagsAreValid(flags)) check is redundant.
>
> ===
>

Updated this.

> (2) COMMENT
> File: src/backend/replication/logical/proto.c
> Function: logicalrep_write_stream_prepare
> +/*
> + * Write STREAM PREPARE to the output stream.
> + * (For stream PREPARE, stream COMMIT PREPARED, stream ROLLBACK PREPARED)
> + */
>
> I think the function comment is outdated because IIUC the stream
> COMMIT PREPARED and stream ROLLBACK PREPARED are not being handled by
> the function logicalrep_write_prepare. SInce this approach seems
> counter-intuitive there needs to be an improved function comment to
> explain what is going on.
>
> ===
>
> (3) COMMENT
> File: src/backend/replication/logical/proto.c
> Function: logicalrep_read_stream_prepare
> +/*
> + * Read STREAM PREPARE from the output stream.
> + * (For stream PREPARE, stream COMMIT PREPARED, stream ROLLBACK PREPARED)
> + */
>
> This is the same as the previous review comment. The function comment
> needs to explain the new handling for stream COMMIT PREPARED and
> stream ROLLBACK PREPARED.
>
> ===

I think that these functions only writing/reading STREAM PREPARE as
the name suggests is more intuitive. Maybe the usage of flags is more
confusing. More below.

>
> (4) COMMENT
> File: src/backend/replication/logical/proto.c
> Function: logicalrep_read_stream_prepare
> +TransactionId
> +logicalrep_read_stream_prepare(StringInfo in, LogicalRepPrepareData
> *prepare_data)
> +{
> + TransactionId xid;
> + uint8 flags;
> +
> + xid = pq_getmsgint(in, 4);
> +
> + /* read flags */
> + flags = pq_getmsgbyte(in);
> +
> + if (!PrepareFlagsAreValid(flags))
> + elog(ERROR, "unrecognized flags %u in prepare message", flags);
>
> I think the logicalrep_write_stream_prepare now can only assign the
> flags = LOGICALREP_IS_PREPARE. So that means the check here for bad
> flags should be changed to match.
> BEFORE: if (!PrepareFlagsAreValid(flags))
> AFTER: if (flags != LOGICALREP_IS_PREPARE)
>
> ===

Updated.

>
> (5) COMMENT
> General
> Since the COMMENTs (2), (3) and (4) are all caused by the refactoring
> that was done for removal of the commit/rollback stream callbacks. I
> do wonder if it might have worked out better just to leave the
> logicalrep_read/write_stream_prepared as it was instead of mixing up
> stream/no-stream handling. A check for stream/no-stream could possibly
> have been made higher up.
>
> For example:
> static void
> pgoutput_commit_prepared_txn(LogicalDecodingContext *ctx, ReorderBufferTXN *txn,
>                              XLogRecPtr prepare_lsn)
> {
>     OutputPluginUpdateProgress(ctx);
>
>     OutputPluginPrepareWrite(ctx, true);
> if (ctx->streaming)
> logicalrep_write_stream_prepare(ctx->out, txn, prepare_lsn);
> else
> logicalrep_write_prepare(ctx->out, txn, prepare_lsn);
>     OutputPluginWrite(ctx, true);
> }
>
> ===

I think I'll keep this as such for now. Amit was talking about
considering removal of flags to overload PREPARE with COMMIT PREPARED
and ROLLBACK PREPARED. Separate functions for each.
Will wait if Amit thinks that is the way to go.

I've also added a new test case for test_decoding for streaming 2PC.
Removed function ReorderBufferTxnIsPrepared as it was never called
thanks to Peter's coverage report. And added stream_prepare to the
list of callbacks that would
enable two-phase commits.

regards,
Ajin Cherian
Fujitsu Australia

Commits

  1. Add prepare API support for streaming transactions in logical replication.

  2. Doc: minor improvements for logical replication protocol documentation.

  3. Fix test failure in 021_twophase.pl.

  4. Refactor to make common functions in proto.c and worker.c.

  5. Unify PostgresNode's new() and get_new_node() methods

  6. Fix potential buffer overruns in proto.c.

  7. Add support for prepared transactions to built-in logical replication.

  8. Refactor function parse_subscription_options.

  9. Allow enabling two-phase option via replication protocol.

  10. Don't use Asserts to check for violations of replication protocol.

  11. Improve psql tab completion for options of subcriptions and publications

  12. Rearrange logrep worker's snapshot handling some more.

  13. doc: Update information of new messages for logical replication.

  14. ALTER SUBSCRIPTION ... ADD/DROP PUBLICATION

  15. Allow pgoutput to send logical decoding messages.

  16. Refactor function parse_output_parameters.

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

  18. Fix an oversight in ReorderBufferFinishPrepared.

  19. Allow multiple xacts during table sync in logical replication.

  20. Fix replication of in-progress transactions in tablesync worker.

  21. Fix 'skip-empty-xacts' option in test_decoding for streaming mode.

  22. Use Enum for top level logical replication message types.

  23. Add support for streaming to built-in logical replication.

  24. Fix the logical streaming test.

  25. Implement streaming mode in ReorderBuffer.

  26. Extend the logical decoding output plugin API with stream methods.

  27. Store 2PC GID in commit/abort WAL recs for logical decoding