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.
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 |