Horton

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

Peter Smith <smithpb2250@gmail.com>

View thread View on postgr.es
From: Peter Smith <smithpb2250@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ajin Cherian <itsajin@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-04-09T09:34:50Z
Lists: pgsql-hackers 
On Fri, Apr 9, 2021 at 6:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Apr 9, 2021 at 12:33 PM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > On Mon, Dec 14, 2020 at 8:27 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > 2.
> > > + /*
> > > + * Flags are determined from the state of the transaction. We know we
> > > + * always get PREPARE first and then [COMMIT|ROLLBACK] PREPARED, so if
> > > + * it's already marked as committed then it has to be COMMIT PREPARED (and
> > > + * likewise for abort / ROLLBACK PREPARED).
> > > + */
> > > + 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;
> > >
> > > I don't like clubbing three different operations under one message
> > > LOGICAL_REP_MSG_PREPARE. It looks awkward to use new flags
> > > RBTXN_COMMIT_PREPARED and RBTXN_ROLLBACK_PREPARED in ReordeBuffer so
> > > that we can recognize these operations in corresponding callbacks. I
> > > think setting any flag in ReorderBuffer should not dictate the
> > > behavior in callbacks. Then also there are few things that are not
> > > common to those APIs like the patch has an Assert to say that the txn
> > > is marked with prepare flag for all three operations which I think is
> > > not true for Rollback Prepared after the restart. We don't ensure to
> > > set the Prepare flag if the Rollback Prepare happens after the
> > > restart. Then, we have to introduce separate flags to distinguish
> > > prepare/commit prepared/rollback prepared to distinguish multiple
> > > operations sent as protocol messages. Also, all these operations are
> > > mutually exclusive so it will be better to send separate messages for
> > > each of these and I have changed it accordingly in the attached patch.
> > >
> >
> > While looking at the two-phase protocol messages (with a view to
> > documenting them) I noticed that the messages for
> > LOGICAL_REP_MSG_PREPARE, LOGICAL_REP_MSG_COMMIT_PREPARED,
> > LOGICAL_REP_MSG_ROLLBACK_PREPARED are all sending and receiving flag
> > bytes which *always* has a value 0.
> >
> > ----------
> > e.g.
> >     uint8       flags = 0;
> >     pq_sendbyte(out, flags);
> >
> > and
> >     /* read flags */
> >     uint8       flags = pq_getmsgbyte(in);
> >     if (flags != 0)
> >         elog(ERROR, "unrecognized flags %u in commit prepare message", flags);
> > ----------
> >
> > I think this patch version v31 is where the flags became redundant.
> >
>
> I think this has been kept for future use similar to how we have in
> logicalrep_write_commit. So, I think we can keep them unused for now.
> We can document it similar commit message ('C') [1].
>
> [1] - https://www.postgresql.org/docs/devel/protocol-logicalrep-message-formats.html
>

Yeah, we can do that. And if nobody else gives feedback about this
then I will do exactly like you suggested.

But I don't understand why we are even trying to "future proof" the
protocol by keeping redundant flags lying around on the off-chance
that maybe one day they could be useful.

Isn't that what the protocol version number is for? e.g. If there did
become some future need for some flags then just add them at that time
and bump the protocol version.

And, even if we wanted to, I think we cannot use these existing flags
in future without bumping the protocol version, because the current
protocol docs say that flag value must be zero!

------
Kind Regards,
Peter Smith.
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