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

On Fri, Nov 20, 2020 at 7:54 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Wed, Nov 18, 2020 at 12:42 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.