Re: pg_reload_conf() synchronously - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_reload_conf() synchronously
Date
Msg-id Y2X0FExL+JzzL+yp@paquier.xyz
Whole thread Raw
In response to Re: pg_reload_conf() synchronously  (Andres Freund <andres@anarazel.de>)
Responses Re: pg_reload_conf() synchronously
List pgsql-hackers
On Fri, Nov 04, 2022 at 09:51:08PM -0700, Andres Freund wrote:
> On 2022-11-04 23:35:21 -0400, Tom Lane wrote:
>> True, but do we have any such cases?
>
> I know I hit it twice and gave up on the tests.

Still, is there any need for a full-blown facility for the case of an
individual backend?  Using a new function to track that all the
changes are in effect is useful for isolation tests, less for single
sessions where a function to wait for all the backends is no different
than a \c to enforce a reload because both tests would need an extra
step (on top of making parallel tests longer if something does a long
transaction?).

As far as I know, Gurjeet has been annoyed only with non-user-settable
GUCs for one connection (correct me of course), there was nothing
fancy with isolation tests, yet.  Not saying that this is useless for
isolation tests, this would have its cases for assumptions where
multiple GUCs need to be synced across multiple sessions, but it seems
to me that we have two different cases in need of two different
solutions.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_reload_conf() synchronously
Next
From: Julien Rouhaud
Date:
Subject: Re: proposal: possibility to read dumped table's name from file