On Thu, Jul 13, 2023 at 11:56 AM Jeff Davis <pg...@j-davis.com> wrote:
>
> 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 ahead).
> if (first_element(search_path) !=
> "dont_override_search_patch_for_maintenance")
> 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
