Re: Commit 5a2fed911a broke parallel query - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Commit 5a2fed911a broke parallel query
Date
Msg-id 1349368.1734968136@sss.pgh.pa.us
Whole thread Raw
In response to Commit 5a2fed911a broke parallel query  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Commit 5a2fed911a broke parallel query
List pgsql-bugs
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> This is a script to reproduce the problem:

As commented in 73c9f91a1,

    This all seems very accidental and probably not the behavior we really
    want, but a security patch is no time to be redesigning things.

Perhaps this thread is a good place to start the discussion.

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.  If we do
want to apply permissions checks in parallel worker start, why
should we think that the failure in this example is wrong?

            regards, tom lane



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #18751: Sub-optimal UNION ALL plan
Next
From: Tom Lane
Date:
Subject: Re: Commit 5a2fed911a broke parallel query