Horton

Re: pgsql: Fix search_path to a safe value during maintenance operations.

Noah Misch <noah@leadboat.com>

View thread View on postgr.es
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>, Jeff Davis <jdavis@postgresql.org>, pgsql-committers@lists.postgresql.org
Date: 2023-06-12T17:05:10Z
Lists: pgsql-hackers 
On Sat, Jun 10, 2023 at 01:33:31AM -0400, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> > Attached a patch to mark those functions as PARALLEL UNSAFE, which
> > fixes the problem.
> 
> > Alternatively, I could just take out that line, as those SQL functions
> > are not controlled by the MAINTAIN privilege. But for consistency I
> > think it's a good idea to leave it in so that index functions are
> > called with the right search path for amcheck.
> 
> I concur with the upthread objection that it is way too late in
> the release cycle to be introducing a breaking change like this.
> I request that you revert it.

The timing was not great, but this is fixing a purported defect in an older
v16 feature.  If the MAINTAIN privilege is actually fine, we're all set for
v16.  If MAINTAIN does have a material problem that $SUBJECT had fixed, we
should either revert MAINTAIN, un-revert $SUBJECT, or fix the problem a
different way.

Commits

  1. Fix search_path to a safe value during maintenance operations.

  2. Revert MAINTAIN privilege and pg_maintain predefined role.

  3. Add grantable MAINTAIN privilege and pg_maintain role.

  4. Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner.