| From: | "Imseih (AWS), Sami" <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Restart pg_usleep when interrupted |
| Date: | 2024-08-13 18:12:30 |
| Message-ID: | b612b9cd-b59e-43d1-bb8a-e100c5ab9849@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2024-08-13 18:22:43 | Re: BlastRADIUS mitigation |
| Previous Message | Jeff Davis | 2024-08-13 17:56:07 | Re: tiny step toward threading: reduce dependence on setlocale() |