Horton

Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: mert@futo.org, pgsql-bugs@lists.postgresql.org
Date: 2025-06-20T21:20:25Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow resetting unknown custom GUCs with reserved prefixes.

  2. Allow ALTER SYSTEM to set unrecognized custom GUCs.

  3. Disallow setting bogus GUCs within an extension's reserved namespace.

On Fri, Jun 20, 2025 at 04:24:41PM -0400, Tom Lane wrote:
> In the case at hand, where the prefix is known but the parameter
> isn't, I think we could safely assume that the setting is either
> a mistake (probably installed while the extension wasn't loaded)
> or the described case of a parameter the extension no longer
> uses.  Either way it seems safe to allow RESET with suitable
> privileges on the target DB and/or role.

I'm a little hesitant to consider opening this up too much.  For example,
what if someone accidentally downgrades the library temporarily and a GUC
definition disappears, or one version of the library removes a parameter
and a future one adds it back (due to user backlash)?  Maybe those
situations are too contrived/unlikely to worry about, though.

> If the prefix is not known, then we're really flying blind.
> It looks like we assume the parameter might be SUSET and therefore
> allow both ALTER DB/ROLE SET and RESET only to superusers.
> I'm hesitant to relax that case.

IIUC we also check pg_parameter_acl in this case, but I agree that we don't
want to relax this any further.

-- 
nathan