Greetings, * Thomas Munro (thomas.mu...@gmail.com) wrote: > On Fri, Mar 10, 2023 at 10:26 AM Melanie Plageman > <melanieplage...@gmail.com> wrote: > > I think that 4753ef37e0ed undid the work caf626b2c did to support > > sub-millisecond delays for vacuum and autovacuum. > > > > After 4753ef37e0ed, vacuum_delay_point()'s local variable msec is a > > double which, after being passed to WaitLatch() as timeout, which is a > > long, ends up being 0, so we don't end up waiting AFAICT. > > > > When I set [autovacuum_]vacuum_delay_point to 0.5, SHOW will report that > > it is 500us, but WaitLatch() is still getting 0 as timeout. > > Given that some of the clunkier underlying kernel primitives have > milliseconds in their interface, I don't think it would be possible to > make a usec-based variant of WaitEventSetWait() that works everywhere. > Could it possibly make sense to do something that accumulates the > error, so if you're using 0.5 then every second vacuum_delay_point() > waits for 1ms?
Hmm. That generally makes sense to me.. though isn't exactly the same. Still, I wouldn't want to go back to purely pg_usleep() as that has the other downsides mentioned. Perhaps if the delay is sub-millisecond, explicitly do the WaitLatch() with zero but also do the pg_usleep()? That's doing a fair bit of work beyond just sleeping, but it also means we shouldn't miss out on the postmaster going away or similar.. Thanks, Stephen
signature.asc
Description: PGP signature
