| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: waiting for reload in tests |
| Date: | 2022-05-10 01:37:46 |
| Message-ID: | YnnB6hXzQ9b4kLWl@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, May 09, 2022 at 09:29:32PM -0400, Tom Lane wrote:
> Brute force way: s/reload/restart/
That was my first thought, as it can be tricky to make sure that all
the processes got the update because we don't publish such a state.
One thing I was also thinking about would be to update
pg_stat_activity.state_change when a reload is processed on top of its
current updates, then wait for it to be effective in all the processes
reported. The field remains NULL for most non-backend processes,
which would be a compatibility change.
> Less brute force: wait for "SHOW variable-you-changed" to report the
> value you expect.
This method may still be unreliable in some processes like a logirep
launcher/receiver or just autovacuum, no?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-05-10 01:42:20 | Re: waiting for reload in tests |
| Previous Message | Tom Lane | 2022-05-10 01:29:32 | Re: waiting for reload in tests |