Re: [HACKERS] logical decoding of two-phase transactions
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] logical decoding of two-phase transactions |
Дата | |
Msg-id | CAA4eK1+hS7wT067xGvfu9o6hGc-t-R1T=FBWpx8CJnr209E_Rw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical decoding of two-phase transactions (Ajin Cherian <itsajin@gmail.com>) |
Ответы |
Re: [HACKERS] logical decoding of two-phase transactions
Re: [HACKERS] logical decoding of two-phase transactions |
Список | pgsql-hackers |
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. [1] - https://www.postgresql.org/message-id/064fab0c-915e-aede-c02e-bd4ec1f59732%402ndquadrant.com [2] - https://www.postgresql.org/message-id/188d15be-8699-c045-486a-f0439c9c2b7d%402ndquadrant.com -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: