Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date
Msg-id 30751.1375447556@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> Perhaps having the file be a heap file instead of anything a sysadmin
> can be asked to go hack would also make it more clear that this is an
> internal PG file which is to be managed only through PG and stop all
> this arguing about how "oh, they can just fix it by twiddling things in
> $PGDATA" is considered by some to be an acceptable solution.

Whether you think it's acceptable or not, sometimes it's *necessary*.
What if you set a combination of parameters that prevents Postgres from
starting?

Even if we could make config-in-a-catalog work, which I'm very dubious
of, I would think it far too unsafe to use.

We could of course fix that problem by only storing "safe" parameters
in a catalog, but then you lose the supposed appeal of a single-file
solution.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Add json_typeof() and json_is_*() functions.
Next
From: Tomasz Nowak
Date:
Subject: Re: inconsistent state after crash recovery