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

On Fri, Jun 30, 2023 at 11:35:46AM -0700, Nathan Bossart wrote:
> On Thu, Jun 29, 2023 at 10:09:21PM -0700, Nathan Bossart wrote:
> > On Thu, Jun 29, 2023 at 08:53:56PM -0400, Tom Lane wrote:
> >> I'm leaning to Robert's thought that we need to revert this for now,
> >> and think harder about how to make it work cleanly and safely.

Another dimension of compromise could be to make MAINTAIN affect fewer
commands in v16. Un-revert the part of commit 05e1737 affecting just the
commands it still affects. For example, limit MAINTAIN and the 05e1737
behavior change to VACUUM, ANALYZE, and REINDEX. Don't worry about VACUUM or
ANALYZE failing under commit 05e1737, since they would have been failing under
autovacuum since 2018. A problem index expression breaks both autoanalyze and
REINDEX, hence the inclusion of REINDEX. The already-failing argument doesn't
apply to CLUSTER or REFRESH MATERIALIZED VIEW, so those commands could join
MAINTAIN in v17.

> > Since it sounds like this is headed towards a revert, here's a patch for
> > removing MAINTAIN and pg_maintain.
>
> I will revert this next week unless opinions change before then. I'm
> currently planning to revert on both master and REL_16_STABLE, but another
> option would be to keep it on master while we sort out the remaining
> issues. Thoughts?

From my reading of the objections, I think they're saying that commit 05e1737
arrived too late and that MAINTAIN is unacceptable without commit 05e1737. I
think you'd conform to all objections by pushing the revert to v16 and pushing
a roll-forward of commit 05e1737 to master.