> None of this seems intractable to me. 1 Hz seems like an entirely
> reasonable place to start, and it is very easy to change (or to even make
> configurable). pg_stat_progress_vacuum might show slightly old values in
> this column, but that should be easy enough to explain in the docs if we
> are really concerned about it. If other callers want to do something
> similar, maybe we should add a more generic implementation in
> backend_progress.c.
>
I don't know if I agree. Making vacuum sleep more robust to handle
interrupts seems like a cleaner general solution than to add
even more code to handle this case or have to explain the behavior of
cost delay instrumentation in docs.
Regards,
Sami
