Re: Commit Timestamp and LSN Inversion issue

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Jan Wieck <jan(at)wi3ck(dot)info>
Cc: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, "tomas(at)vondra(dot)me" <tomas(at)vondra(dot)me>
Subject: Re: Commit Timestamp and LSN Inversion issue
Date: 2024-11-08 09:51:47
Message-ID: CAA4eK1JVad8n=pQFfGTfn+ZrTaFXx87w0dHpuN+30mf9_OZTRg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 7, 2024 at 9:39 PM Jan Wieck <jan(at)wi3ck(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2024-11-08 10:18:09 Re: define pg_structiszero(addr, s, r)
Previous Message wenhui qiu 2024-11-08 09:49:45 Re: pg_stat_statements: Avoid holding excessive lock