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

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/