MIME-Version: 1.0
References: <e44327179e5c9015c8dda67351c04da552066017.camel@j-davis.com>
 <b701501541a424111ffe47be055e0ccefefd7745.camel@j-davis.com> <2cf41c8edeaaf7acb757095e6eceab8ae926f3da.camel@j-davis.com>
In-Reply-To: <2cf41c8edeaaf7acb757095e6eceab8ae926f3da.camel@j-davis.com>
From: Gurjeet Singh <gurjeet@singh.im>
Date: Thu, 13 Jul 2023 12:54:26 -0700
Message-ID: <CABwTF4XWKqx06UxApH8pnBdp_w2iL6VEbGKxDyjCW7-FNhLCBQ@mail.gmail.com>
Subject: Re: Fix search_path for all maintenance commands
To: Jeff Davis <pgsql@j-davis.com>
Cc: pgsql-hackers@postgresql.org, Nathan Bossart <nathandbossart@gmail.com>, 
	Robert Haas <robertmhaas@gmail.com>, Noah Misch <noah@leadboat.com>, 
	"David G. Johnston" <david.g.johnston@gmail.com>, Greg Stark <stark@mit.edu>, Tom Lane <tgl@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CABwTF4XWKqx06UxApH8pnBdp_w2iL6VEbGKxDyjCW7-FNhLCBQ%40mail.gmail.com>
Precedence: bulk

On Thu, Jul 13, 2023 at 11:56=E2=80=AFAM Jeff Davis <pgsql@j-davis.com> wro=
te:
>
> The current approach seemed to get support from Noah, Nathan, and Greg
> Stark.
>
> Concerns were raised by Gurjeet, Tom, and Robert in the 16 cycle; but

I didn't see Tom's or Robert's concerns raised in this thread. I see
now that for some reason there are two threads with slightly different
subjects. I'll catch-up on that, as well.

The other thread's subject: "pgsql: Fix search_path to a safe value
during maintenance operations"

> I'm not sure whether those objections were specific to the 16 cycle or
> whether they are objections to the approach entirely. Comments?

The approach seems good to me. My concern is with this change's
potential to cause an extended database outage. Hence sending it out
as part of v16, without any escape hatch for the DBA, is my objection.

It it were some commercial database, we would have simply introduced a
hidden event, or a GUC, with default off. But a GUC for this feels too
heavy handed.

Perhaps we can provide an escape hatch as follows (warning, pseudocode ahea=
d).

> if (first_element(search_path) !=3D "dont_override_search_patch_for_maint=
enance")
>      SetConfigOption("search_path", GUC_SAFE_SEARCH_PATH, ...);

So, if someone desperately wants to just plow through the maintenance
command, and are not ready or able to fix their dependence on their
search_path, the community can show them this escape-hatch.

Best regards,
Gurjeet
http://Gurje.et