Horton

Re: MAINTAIN privilege -- what do we need to un-revert it?

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: pgsql-hackers@postgresql.org, Joe Conway <mail@joeconway.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2024-02-14T19:02:26Z
Lists: pgsql-hackers 
On Wed, Feb 14, 2024 at 10:20:28AM -0800, Jeff Davis wrote:
> If those arguments are still unconvincing, then the next idea is to fix
> the search_path for all maintenance commands[3]. I tried this during
> the 16 cycle, but due to timing issues it was also reverted. I can
> proceed with this approach again, but I'd like a clear endorsement, in
> case there were other reasons to doubt the approach.

This seemed like the approach folks were most in favor of at the developer
meeting a couple weeks ago [0].  At least, that was my interpretation of
the discussion.

BTW I have been testing reverting commit 151c22d (i.e., un-reverting
MAINTAIN) every month or two, and last I checked, it still applies pretty
cleanly.  The only changes I've needed to make are to the catversion and to
a hard-coded version in a test (16 -> 17).

[0] https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2024_Developer_Meeting#The_Path_to_un-reverting_the_MAINTAIN_privilege

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Commits

  1. doc: Note that CREATE MATERIALIZED VIEW restricts search_path.

  2. Small refactoring around ExecCreateTableAs().

  3. Add is_create parameter to RefreshMatviewByOid().

  4. Remove unused ParamListInfo argument from ExecRefreshMatView.

  5. When creating materialized views, use REFRESH to load data.

  6. Add missing RestrictSearchPath() calls.

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

  8. Revert MAINTAIN privilege and pg_maintain predefined role.

  9. Avoid repeated name lookups during table and index DDL.

  10. Add a materialized view relations.