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

From Andres Freund
Subject Re: pg_reload_conf() synchronously
Date
Msg-id 20221105182256.x7mugegel7fk4ijs@awork3.anarazel.de
Whole thread Raw
In response to Re: pg_reload_conf() synchronously  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_reload_conf() synchronously
List pgsql-hackers
Hi,

On 2022-11-05 14:26:44 +0900, Michael Paquier wrote:
> 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?

No, and I didn't claim it was.


> Using a new function to track that all the changes are in effect is useful
> for isolation tests

I hit it in tap tests, fwiw.


> 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.

I didn't say we need to go for something more complete. Just that it's worth
thinking about.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] ALTER TABLE ... SET STORAGE default
Next
From: Andres Freund
Date:
Subject: Re: [PATCH] Add native windows on arm64 support