From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Commit 5a2fed911a broke parallel query
Date: Mon, 23 Dec 2024 18:39:33 +0100
Message-ID: <e507393acfe3cd76f7a1901d27092c58b891903c.camel@cybertec.at> (raw)
In-Reply-To: <1408486.1734973973@sss.pgh.pa.us>
References: <8befc845430ba1ae3748af900af298788e579c89.camel@cybertec.at>
<1349368.1734968136@sss.pgh.pa.us>
<1408486.1734973973@sss.pgh.pa.us>
On Mon, 2024-12-23 at 12:12 -0500, Tom Lane wrote:
> I wrote:
> > In the security-team discussion that led up to 73c9f91a1, I'd been
> > wondering why parallel worker start enforces any connection
> > restrictions at all. If we'd like the use of parallelism to be
> > more-or-less transparent, we shouldn't apply these checks,
> > and not the !am_superuser ones in InitPostgres either.
>
> That is, the way I'd prefer to attack this is something along the
> lines of the attached, which just disables all those checks in
> parallel workers (and reverts 73c9f91a1's hackery on am_superuser).
>
> One big question this raises is whether any other sorts of background
> processes should be treated similarly.
>
> Another loose end is that I don't think the enforcement of
> datconnlimit is very sane. CountDBBackends skips processes that say
> AmBackgroundWorkerProcess, so logically those should be precisely the
> ones that escape enforcement of datconnlimit, but it doesn't quite
> work like that today. This patch at least puts parallel workers on
> the right side of the line; but I think we have some cleanup to do
> for other sorts of auxiliary processes.
>
> I'm also wondering if we could revisit the need for
> CheckMyDatabase's override_allow_connections parameter
> and thereby remove INIT_PG_OVERRIDE_ALLOW_CONNS.
> So all in all, this is just at the POC stage.
Thanks for looking at this problem.
I think that disabling the connect privilege check for parallel
workers is the right thing to do. Getting permission problems just
because PostgreSQL decided to use parallel query doesn't make any sense.
I'm not sure about other background workers, but my guts say that
they shouldn't check for the connect privilege either.
I agree that background workers shouldn't count against a connection
limit, but against "max_worker_processes".
Yours,
Laurenz Albe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: laurenz.albe@cybertec.at, tgl@sss.pgh.pa.us, pgsql-bugs@lists.postgresql.org
Subject: Re: Commit 5a2fed911a broke parallel query
In-Reply-To: <e507393acfe3cd76f7a1901d27092c58b891903c.camel@cybertec.at>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox