Re: pg_reload_conf() synchronously

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gurjeet Singh <gurjeet(at)singh(dot)im>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_reload_conf() synchronously
Date: 2022-11-05 18:22:56
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-11-05 18:31:36 Re: [PATCH] Add native windows on arm64 support
Previous Message Tom Lane 2022-11-05 17:45:59 Re: [PATCH] ALTER TABLE ... SET STORAGE default