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
