From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Restart pg_usleep when interrupted |
Date: | 2024-07-12 07:54:51 |
Message-ID: | ZpDhS4nFX66ItAze@ip-10-97-1-34.eu-west-3.compute.internal |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Thu, Jul 11, 2024 at 10:15:41AM -0500, Sami Imseih wrote:
>
> > I did a few tests with the patch and did not see any "large" drifts like the
> > ones observed above.
>
> Thanks for testing.
>
> > I think it could be "simplified" by making use of instr_time instead of timespec
> > for current and absolute. Then I think it would be enough to compare their
> > ticks.
>
> Correct I attached a v2 of this patch that uses instr_time to check the elapsed
> time and break out of the loop. It needs some more benchmarking.
Thanks!
Outside of Nathan's comment:
1 ===
+ * However, since nanosleep is susceptible to time drift when interrupted
+ * frequently, we add a safeguard to break out of the nanosleep whenever the
I'm not sure that "nanosleep is susceptible to time drift when interrupted frequently"
is a correct wording.
What about?
"
However, since the time between frequent interruptions and restarts of the
nanosleep calls can substantially lead to drift in the time when the sleep
finally completes, we add...."
2 ===
+static void vacuum_sleep(double msec);
What about a more generic name that could be used outside of vacuum?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Kukushkin | 2024-07-12 09:00:24 | Re: pg_rewind WAL segments deletion pitfall |
Previous Message | Sutou Kouhei | 2024-07-12 07:24:06 | Re: pg_rewind WAL segments deletion pitfall |