Hi,
On 2022-11-05 12:03:49 -0700, Gurjeet Singh wrote:
> For example, I thought of implementing DSM based synchronisation between
> processes, so that the invoking backend can be sure that _all_ children of
> Postmaster have processed the reload. But that will run into problems as
> different
On Sat, Nov 5, 2022 at 11:23 AM Andres Freund wrote:
> > 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
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
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?
Hi,
On 2022-11-04 23:35:21 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Worth noting that this doesn't necessarily suffice to avoid race conditions
> > in
> > tests, if the test depends on *other* backends having seen the configuration
> > changes.
>
> True, but do we have any such
Andres Freund writes:
> Worth noting that this doesn't necessarily suffice to avoid race conditions in
> tests, if the test depends on *other* backends having seen the configuration
> changes.
True, but do we have any such cases?
> It might be worth to use the global barrier mechanism to count
Hi,
On 2022-11-04 10:26:38 -0700, Gurjeet Singh wrote:
> The attached patch makes the pg_reload_conf() function set
> ConfigReloadPending to true, which will force the postgres main
> command-processing loop to process and apply config changes _before_
> executing the next command.
Worth noting
In an internal conversation it was seen that for some tests that want
to enforce a behaviour, a behaviour that is controlled by a GUC, we
_need_ to perform a sleep for an arbitrary amount of time.
Alternatively, executing the rest of the test on a new connection also
helps to get the expected
