On Wed, Aug 7, 2013 at 10:59:05AM -0400, Alvaro Herrera wrote:
> > If we do this, perhaps we should unconditionally just print the file
> > name they have to delete to undo the operation in case the server
> > doesn't start;
>
> However, bear in mind that if the DBA is administering a server through
> ALTER SYSTEM and they don't have shell access, they might just be
> screwed if they bollix the system and they lose access. Knowing what
> file you have to delete does you no good if you can't actually delete it.
My point was that if we tell them what file they have to edit to undo a
problem, then at least then know that there is chance this will require
shell access, and they can undo the change right there (with SET var =
DEFAULT?) e.g.:
WARNING: If this change prevents the server from starting, you will
need to edit postgresql.conf.auto to undo the change
> > I am unclear we can clearly identify all the GUC
> > settings that could cause a server not to start. Also, I think we need
> > a SHOW SYSTEM command so users can see their settings via SQL.
>
> Not sure about this. SHOW normally just displays the current value,
> nothing more. If you want more details, there's the pg_settings view
> with complete information.
The issue is that if we give users the ability to set values via SQL, we
should at least document how they can view the things they set via SQL,
and pg_settings doesn't do that because it just shows the _active_
value, which might have overridden the SQL-set value.
Right now we can see settings in postgresql.conf by viewing the file,
and ALTER USER/DATABASE via system tables. Having no API to view
SQL-set values except viewing a flat file seems counter-productive.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
