Horton

Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Stephen Frost <sfrost@snowman.net>
Date: 2023-03-09T22:37:47Z
Lists: pgsql-hackers 
On Thu, Mar 09, 2023 at 05:27:08PM -0500, Tom Lane wrote:
> Is it reasonable to assume that all modern platforms can time
> millisecond delays accurately?  Ten years ago I'd have suggested
> truncating the delay to a multiple of 10msec and using this logic
> to track the remainder, but maybe now that's unnecessary.

If so, it might also be worth updating or removing this comment in
pgsleep.c:

     * NOTE: although the delay is specified in microseconds, the effective
     * resolution is only 1/HZ, or 10 milliseconds, on most Unixen.  Expect
     * the requested delay to be rounded up to the next resolution boundary.

I've had doubts for some time about whether this is still accurate...

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Commits

  1. Use nanosleep() to implement pg_usleep().

  2. Update obsolete comment about pg_usleep() accuracy.

  3. Fix fractional vacuum_cost_delay.