Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag
Date
Msg-id 159529.1696868418@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> Another thing is that we cannot rely on the PID returned by launch()
> as it could fail, so $worker3_pid needs to disappear.  If we do that,
> I'd rather just switch to a specific database for the tests with
> ALLOWCONN rather than reuse "mydb" that could have other workers.

Right.

> The
> attached fixes the issue for me.

Hmm.  This passed a few dozen test cycles on mamba's host,
but it seems to me there's still a race condition here:

$result = $node->safe_psql('postgres',
    "SELECT count(*) FROM pg_stat_activity WHERE datname = 'noconndb';");
is($result, '0', 'dynamic bgworker without BYPASS_ALLOWCONN not started');

There will be a window where the worker has logged "database
"noconndb" is not currently accepting connections" but hasn't yet
exited, so that conceivably this query could see a positive count.

We could just drop this test, reasoning that the appearance of
the error message is sufficient evidence that the right thing
happened.  (If the failed worker is still around, it won't break
the remaining tests AFAICS.)  Or we could convert this to a
poll_query_until() loop.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: should frontend tools use syncfs() ?
Next
From: "David G. Johnston"
Date:
Subject: Re: Fix output of zero privileges in psql