Re: Possibility to disable `ALTER SYSTEM`

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: Possibility to disable `ALTER SYSTEM`
Дата
Msg-id CABV9wwMkqnqWW1Y0XCO+Aj_sYuq+4TOhsVVUumM46Wrq0-42eQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Possibility to disable `ALTER SYSTEM`  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On Wed, Mar 20, 2024 at 10:31 PM Magnus Hagander <magnus@hagander.net> wrote:
>
> On Wed, Mar 20, 2024 at 8:52 PM Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Wed, Mar 20, 2024 at 3:17 PM Magnus Hagander <magnus@hagander.net> wrote:
>> > Right, what I meant is that making it a packaging decision is the better place. Wherever it goes, allowing the
administratorto choose what fits them should be made possible. 
>>
>> +1. Which is also the justification for this patch, when it comes
>> right down to it. The administrator gets to decide how the contents of
>> postgresql.conf are to be managed on their particular installation.
>
>
> Not really. The administrator can *already* do that. It's trivial.
>
> This patch is about doing it in a way that doesn't produce as ugly a message.But if we're "delegating" it to
packagersand "os administrators", then the problem is already solved. This patch is about trying to solve it *without*
involvingthe packagers or OS administrators. 
>
> Not saying we shouldn't do it, but I'd argue the exact opposite of yours aboe, which is that it's very much not the
justificationof the patch :) 
>
>
>>
>> They can decide that postgresql.conf should be writable by the same
>> user that runs PostgreSQL, or not. And they should also be able to
>> decide that ALTER SYSTEM is an OK way to change configuration, or that
>> it isn't. How we enable them to make that decision is a point for
>> discussion, and how exactly we phrase the documentation is a point for
>> discussion, but we have no business trying to impose conditions, as if
>> they're only allowed to make that decision if they conform to some
>> (IMHO ridiculous) requirements that we dictate from on high. It's
>> their system, not ours.
>
>
> Agreed on all those except they can already do this. It's just that the error message is ugly. The path of least
resistancewould be to just specifically detect a permissions error on the postgresql.auto.conf file when you try to do
ALTERSYSTEM, and throw at least an error hint about "you must allow writing to this file for the feature to work". 
>
> So this patch isn't at all about enabling this functionality. It's about making it more user friendly.
>
>
>> I mean, for crying out loud, users can set enable_seqscan=off in
>> postgresql.conf and GLOBALLY DISABLE SEQUENTIAL SCANS. They can set
>
>
> This is actually a good example, because it's kind of like this patch. It doesn't *actually* disable the ability to
runsequential scans, it just disables the "usual way". Just like this patch doesn't prevent the superuser from editing
theconfig, but it does prevent them droin doing it "the usual way". 
>
>
>>
>> zero_damaged_pages=on in postgresql.conf and silently remove vast
>> quantities of data without knowing that they're doing anything. We
>> don't even question that stuff ... although we probably should be
>
>
> I like how you got this far and didn't even mention fsync=off :)
>

And yet somehow query hints are more scary than ALL of these things. Go figure!

Robert Treat
https://xzilla.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: SQL:2011 application time
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs