MIME-Version: 1.0
References: <CAJpy0uBxEJnabEp3JS=n9X19Vx2ZK3k5AR7N0h-cSMtOwYV3fA@mail.gmail.com>
 <CAJ7c6TNZY3idBDoGOaoS_fF6vJuBMjnDhZC4i5V0J58s2SJ3AA@mail.gmail.com>
 <CAA4eK1LOmtMpmJAxsmN0yXJb-Q9vi6KThDYXdpVGL_WZW5ZgvQ@mail.gmail.com>
 <CAJ7c6TOcQPcydC7HW=xPEDN6_Ec7iSTP9j=1VTAeG=haguOQHw@mail.gmail.com>
 <CAA4eK1KhAxe6=VTxa6xEbc22_VVBLsVuvRH8Wxws8i50gH=eqw@mail.gmail.com>
 <9f7f4def-7ea8-4ad3-83e7-a8cc9d18c58a@wi3ck.info> <OS0PR01MB57162A0406EFBB133C9F747E945C2@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <17a7ce08-f04a-49ab-af5c-233d616d7c3b@wi3ck.info>
In-Reply-To: <17a7ce08-f04a-49ab-af5c-233d616d7c3b@wi3ck.info>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Fri, 8 Nov 2024 15:21:47 +0530
Message-ID: <CAA4eK1JVad8n=pQFfGTfn+ZrTaFXx87w0dHpuN+30mf9_OZTRg@mail.gmail.com>
Subject: Re: Commit Timestamp and LSN Inversion issue
To: Jan Wieck <jan@wi3ck.info>
Cc: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Aleksander Alekseev <aleksander@timescale.com>, 
	pgsql-hackers <pgsql-hackers@postgresql.org>, shveta malik <shveta.malik@gmail.com>, 
	"tomas@vondra.me" <tomas@vondra.me>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAA4eK1JVad8n%3DpQFfGTfn%2BZrTaFXx87w0dHpuN%2B30mf9_OZTRg%40mail.gmail.com>
Precedence: bulk

On Thu, Nov 7, 2024 at 9:39=E2=80=AFPM 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 thin=
gs.
> >
> > 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 curren=
tly do
> > not have the handling of timestamps for other nodes. Should we either r=
emove
> > this part or add a brief explanation to clarify the relationship with o=
ther
> > 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
--=20
With Regards,
Amit Kapila.