| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | "Imseih (AWS), Sami" <samimseih(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 16:40:27 |
| Message-ID: | ZruMe-ppopQX4uP8@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 13, 2024 at 11:07:46AM -0500, Imseih (AWS), Sami wrote:
> Having to add special handling to space out instrumentation
> directly in vacuum_delay_point seems very odd to me. I don't
> think vacuum_delay_point should have to worry about this.
>
> Also,
> 1/ what is an appropriate interval to collect these stats?
> 2/ What if there are other callers in the future that wish
> to instrument parallel vacuum workers? they will need to implement
> similar logic.
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.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-08-13 17:19:34 | Re: pg_verifybackup: TAR format backup verification |
| Previous Message | Imseih (AWS), Sami | 2024-08-13 16:15:56 | Re: Restart pg_usleep when interrupted |