Re: [HACKERS] logical decoding of two-phase transactions
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] logical decoding of two-phase transactions |
Дата | |
Msg-id | CAA4eK1+yxdbRG2Qu-f76sfwVLCwNQS8-rfns7F4A7q69u3mDBQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical decoding of two-phase transactions (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | 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 по дате отправления: