Re: [HACKERS] logical decoding of two-phase transactions - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] logical decoding of two-phase transactions
Date
Msg-id CAA4eK1+yxdbRG2Qu-f76sfwVLCwNQS8-rfns7F4A7q69u3mDBQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical decoding of two-phase transactions  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Fri, Nov 20, 2020 at 7:54 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Nov 18, 2020 at 12:42 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > > 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.
>

Thanks for the confirmation. Your review and suggestions are quite helpful.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions