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 |
Message-ID: | 20221105182256.x7mugegel7fk4ijs@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
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 |