Re: Granting SET and ALTER SYSTE privileges for GUCs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <joe(at)crunchydata(dot)com>
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Date: 2022-03-28 18:31:47
Message-ID: 892024.1648492307@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I've started reviewing this patch in earnest, and almost immediately
hit a serious problem: these regression tests aren't even a little bit
committable. For one thing, they fail if you do "make installcheck"
twice in a row. This seems to be because the first run leaves some
cruft behind in pg_parameter_acl that affects the results of
subsequent runs. But the bigger problem is that it is ABSOLUTELY NOT
OKAY to test ALTER SYSTEM during an "installcheck" run. That would be
true even if you cleaned up all the settings by the end of the run, as
the patch fails to do (and for extra demerit, it leaves a superuser
role laying around). Even transient effects on the behavior of
sessions in other DBs aren't acceptable in installcheck mode, IMO.

I think we probably have to trash the core-regression-tests part of
the patch altogether and instead use a TAP test for whatever testing
we want to do. It might be all right to test SET privileges without
testing ALTER SYSTEM, but I'm not sure there's much point in that.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2022-03-28 18:38:25 Re: Proposal: Support custom authentication methods using hooks
Previous Message Nikola Ivanov 2022-03-28 18:31:35 Re: SQL/JSON: functions