Skimming the last few messages of that thread [0], it looks like Bertrand
is exploring ways to avoid so many interrupts. I guess the unavoidable
question is whether this work is still worthwhile given that improvement.
The way the instrumentation in [0] dealt with interrupts was too complex,
which is why it seemed better to handle the restart the remainder of the
sleep in the sleep function
On the patch itself: Making the sleeps in vacuum uninterruptible means that
vacuum will be more slow to respond to interrupts. If you SIGTERM a vacuum
process, or hit CTRL-C, you *would* want to exit the sleep ASAP.
Since the delay will typically be pretty small (2 milliseconds by default
for autovacuum), I'm assuming this won't ordinarily be noticeable. But I
do think it is an important consideration.
At most, the sleep will be 100ms for vacuum.
Tom raised that concern earlier in this thread
(https://www.postgresql.org/message-id/2100439.1719610468%40sss.pgh.pa.us),
but it seems the discussion wandered off to the details of how to do
the sleep, and left that unaddressed.
Doing something like pg_sleep, using WaitLatch [1], was explored.
However this
does not support microsecond sleeps which was allowed in 720de00af49
Thomas shared WaitLatchUs [2], which supports higher precision sleeps, but
it requires epoll_pwait(2) on the system, thus it's not very portable.
Using nanosleep with remain time and checking for drift was the most
portable
approach.
Regards,
Sami
[0] https://commitfest.postgresql.org/49/5027/
[1]
https://www.postgresql.org/message-id/67072E39-3B4E-4240-8373-AC45E23721E7%40gmail.com
[2]
https://www.postgresql.org/message-id/CA+hUKGKVbJE59JkwnUj5XMY+-rzcTFciV9vVC7i=lufwpds...@mail.gmail.com
