Horton

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

Masahiko Sawada <sawada.mshk@gmail.com>

View thread View on postgr.es
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ajin Cherian <itsajin@gmail.com>, Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-11-20T02:24:16Z
Lists: pgsql-hackers 
On Wed, Nov 18, 2020 at 12:42 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Nov 18, 2020 at 7:54 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Tue, Nov 17, 2020 at 9:05 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Tue, Nov 17, 2020 at 5:02 PM Ajin Cherian <itsajin@gmail.com> wrote:
> > > >
> > > > On Tue, Nov 17, 2020 at 10:14 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > >
> > > > >
> > > > > Doesn't this happen only if you set replication origins? Because
> > > > > otherwise both PrepareTransaction() and
> > > > > RecordTransactionCommitPrepared() used the current timestamp.
> > > > >
> > > >
> > > > I was also checking this, even if you set replicating origins, the
> > > > preparedTransaction will reflect the local prepare time in
> > > > pg_prepared_xacts. pg_prepared_xacts fetches this information
> > > > from GlobalTransaction data which does not store the origin_timestamp;
> > > > it only stores the prepared_at which is the local timestamp.
> > > >
> > >
> > > Sure, but my question was does this difference in behavior happens
> > > without replication origins in any way? The reason is that if it
> > > occurs only with replication origins, I don't think we need to bother
> > > about the same because that feature is not properly implemented and
> > > not used as-is. See the discussion [1] [2]. OTOH, if this behavior can
> > > happen without replication origins then we might want to consider
> > > changing it.
> >
> > Logical replication workers always have replication origins, right? Is
> > that what you meant 'with replication origins'?
> >
>
> I was thinking with respect to the publisher-side but you are right
> that logical apply workers always have replication origins so the
> effect will be visible but I think the same should be true on
> publisher without this patch as well. Say, the user has set up
> replication origin via pg_replication_origin_xact_setup and provided a
> value of timestamp then also the same behavior will be there.

Right.

>
> > IIUC logical replication workers always set the origin's commit
> > timestamp as the commit timestamp of the replicated transaction. OTOH,
> > the timestamp of PREPARE, ‘prepare’ of pg_prepared_xacts, always uses
> > the local timestamp even if the caller of PrepareTransaction() sets
> > replorigin_session_origin_timestamp. In terms of user-visible
> > timestamps of transaction operations, I think users might expect these
> > timestamps are matched between the origin and its subscribers. But the
> > pg_xact_commit_timestamp() is a function of the commit timestamp
> > feature whereas ‘prepare’ is a pure timestamp when the transaction is
> > prepared. So I’m not sure these timestamps really need to be matched,
> > though.
> >
>
> Yeah, I am not sure if it is a good idea for users to rely on this
> especially if the same behavior is visible on the publisher as well.
> We might want to think separately if there is a value in making
> prepare-time to also rely on replorigin_session_origin_timestamp and
> if so, that can be done as a separate patch. What do you think?

I agree that we can think about it separately. If it's necessary we
can make a patch later.

Regards,

-- 
Masahiko Sawada
EnterpriseDB:  https://www.enterprisedb.com/

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