> 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
