Re: Overhauling GUCS
От | Tom Lane |
---|---|
Тема | Re: Overhauling GUCS |
Дата | |
Msg-id | 17932.1212415926@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Overhauling GUCS (Greg Smith <gsmith@gregsmith.com>) |
Ответы |
Re: Overhauling GUCS
Re: Overhauling GUCS Re: Overhauling GUCS Re: Overhauling GUCS |
Список | pgsql-hackers |
Greg Smith <gsmith@gregsmith.com> writes: > Joshua has been banging a drum for a while now that all this data needs to > get pushing into the database itself. This is, very simply, not going to happen. Shall we go over the reasons why not, one more time? 1. Quite a few of the GUC parameters are needed *before* one can ever read the database; in particular the ones about file locations and shared memory sizing. 2. Suppose you change a parameter in a way that breaks the DB (eg, set shared_buffers to a value larger than your kernel allows) and try to restart. Database doesn't start. If the parameter can only be changed back within an operating database, you're hosed. I have no objection to providing alternative ways to edit the configuration data, but the primary source of the settings is going to continue to be an editable text file. Any proposals for alternatives-to-a-text-editor have to work within that reality. regards, tom lane
В списке pgsql-hackers по дате отправления: