> time. I wouldn't say I'm diametrically opposed to this patch, but I do
> think we need to carefully consider whether it's worth the extra code.
FWIW, besides the patch that Bertrand is proposing [1], there is another parallel
vacuum case being discussed to allow for parallel heap scan [2].
Being able to support both instrumentation of sleep time by a parallel workers
and ensuring that actual sleep times are as close as possible to the
requested times is a good think, IMO.
> Separately, I've been wondering whether it's worth allowing the sleep to be
> interrupted in certain cases, such as SIGINT and SIGTERM. That should
> address one of Heikki's points.
An idea may be to check for pending interrupts inside the
pg_usleep_non_interruptible nanosleep loop. If there is a
pending interrupt and the interrupt is QueryCancelPending or
ClientConnectionLost, we can break out immediately.
I am not sure yet how this can work for Windows, since for
this patch, we are using a simple SleepEx call which is
non-interruptible anyhow.
Is it worth the effort and even more code to deal with specific
Interrupts for such short sleeps ( less than 100ms for vacuum at most )?
I am also thinking that pg_usleep_non_interruptuble routine should have
a cap on the sleep time allowed. That cap can be 100ms to match the
max vacuum_cost_delay. This will prevent anyone from trying to use
this API for much longer sleeps.
What do you think?
[1] https://www.postgresql.org/message-id/flat/ZmaXmWDL829fzAVX%40ip-10-97-1-34.eu-west-3.compute.internal
[2] https://www.postgresql.org/message-id/CAD21AoAEfCNv-GgaDheDJ%2Bs-p_Lv1H24AiJeNoPGCmZNSwL1YA%40mail.gmail.com
Regards,
Sami
