From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag |
Date: | 2023-10-09 22:37:49 |
Message-ID: | ZSSAvZNDYZgrNvfX@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 09, 2023 at 12:20:18PM -0400, Tom Lane wrote:
> 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.
I don't think that's possible here. The check on datallowconn is done
before a backend calls pgstat_bestart() which would make its backend
entry reported to pg_stat_activity. So there is no window where a
backend would be in pg_stat_activity if this check fails.
> 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.
Saying that, I'm OK with just dropping this query, as it could also be
possible that one decides that calling pgstat_bestart() before the
datallowconn check is a good idea for a reason or another.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-10-09 23:08:05 | Lowering the default wal_blocksize to 4K |
Previous Message | Robert Haas | 2023-10-09 22:31:11 | Re: New WAL record to detect the checkpoint redo location |