Re: Commit Timestamp and LSN Inversion issue - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Commit Timestamp and LSN Inversion issue
Date
Msg-id CAA4eK1JVad8n=pQFfGTfn+ZrTaFXx87w0dHpuN+30mf9_OZTRg@mail.gmail.com
Whole thread Raw
In response to Commit Timestamp and LSN Inversion issue  (shveta malik <shveta.malik@gmail.com>)
List pgsql-hackers
On Thu, Nov 7, 2024 at 9:39 PM Jan Wieck <jan@wi3ck.info> wrote:
>
> On 11/6/24 21:30, Zhijie Hou (Fujitsu) wrote:
> >
> > Thanks for the patch! I am reading the patch and noticed few minor things.
> >
> > 1.
> > +     /*
> > +      * This is a local transaction. Make sure that the xact_time
> > +      * higher than any timestamp we have seen thus far.
> > +      *
> > +      * TODO: This is not postmaster restart safe. If the local
> > +      * system clock is further behind other nodes than it takes
> > +      * for the postmaster to restart (time between it stops
> > +      * accepting new transactions and time when it becomes ready
> > +      * to accept new transactions), local transactions will not
> > +      * be bumped into the future correctly.
> > +      */
> >
> > The TODO section mentions other nodes, but I believe think patch currently do
> > not have the handling of timestamps for other nodes. Should we either remove
> > this part or add a brief explanation to clarify the relationship with other
> > nodes?
>
> That TODO is actually obsolete. I understood from Amit Kapila that the
> community does assume that NTP synchronization is good enough.
>

This is my understanding from the relevant discussion in the email thread [1].

[1] - https://www.postgresql.org/message-id/2423650.1726842094%40sss.pgh.pa.us
--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: wenhui qiu
Date:
Subject: Re: pg_stat_statements: Avoid holding excessive lock
Next
From: David Rowley
Date:
Subject: Re: define pg_structiszero(addr, s, r)