I'm trying to understand what the point of this patch is, so I went to
read this thread from the beginning:
In the proposal by Bertrand [1] to implement vacuum cost delay tracking
in pg_stat_progress_vacuum, it was discovered that the vacuum cost delay
ends early on the leader process of a parallel vacuum due to parallel workers >
reporting progress on index vacuuming, which was introduced in 17
with commit [2]. With this patch, everytime a parallel worker
completes a vacuum index, it will send a completion message to the leader.
Ok, so we might sometimes skip the sleep, if an interrupt is received. I
agree that's a bit sloppy, but probably won't make any difference in
practice.
The facility that allows a parallel worker to report progress to the leader was
introduced in commit [3].
In the case of the patch being proposed by Bertrand, the number of interrupts > will be much more frequent as parallel workers would send a message
to the leader
to update the vacuum delay counters every vacuum_delay_point call.
Hmm, I wonder if that's a good design, if it results in a lot of interrupts.
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.
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.
--
Heikki Linnakangas
Neon (https://neon.tech)
