Hi,
On 2022-05-09 21:42:20 -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Mon, May 09, 2022 at 09:29:32PM -0400, Tom Lane wrote:
> >> Less brute force: wait for "SHOW variable-you-changed" to report the
> >> value you expect.
>
> > This method may still be unreliable in some processes l
Michael Paquier writes:
> On Mon, May 09, 2022 at 09:29:32PM -0400, Tom Lane wrote:
>> 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?
Yeah
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_ac
Andres Freund writes:
> In a couple tests I (IIRC others as well) had the problem that a config reload
> isn't actually synchronous. I.e. a sequence like
> $node_primary->reload;
> $node_primary->safe_psql('postgres',...)
> isn't actually guaranteed to observe the config as reloaded in the the
>
