Re: Improving postgresql.conf
От | Michael Glaesemann |
---|---|
Тема | Re: Improving postgresql.conf |
Дата | |
Msg-id | 457109FD-BF68-11D8-846A-000A95C88220@myrealbox.com обсуждение исходный текст |
Ответ на | Re: Improving postgresql.conf (Christopher Kings-Lynne <chriskl@familyhealth.com.au>) |
Ответы |
Re: Improving postgresql.conf
Re: Improving postgresql.conf |
Список | pgsql-hackers |
On Jun 16, 2004, at 1:05 PM, Christopher Kings-Lynne wrote: >>> The proposal is to remove the comments from postgresql.conf (like >>> Apache) so all entries will be active. The downside is that it will >>> not >>> be possible to determine which values were modified from their >>> defaults. > > One thing that truly annoys me about postgresql.conf is say I unhash > an option and set it to something. Then I reload. Then I edit the > conf and hash it out again, then I reload. Of course, the option > still has my old value. This is really annoying and I've wasted lots > of time trying to figure out what's going on. A habit I've gotten into for editing config files that have commented defaults is to copy the line with the setting, uncomment the copied line, and change it to my setting. Would it help to have two lines in the config file for each setting, one with the default (comment) and one with the actual setting? So for example, the postgresql.conf would ship with something like this: #tcpip_socket = false #default tcpip_socket = false If the user wants to connect via tcp_ip, they can edit it like this: #tcpip_socket = false #default tcpip_socket = true The default is still there for reference, and they can see what the current setting is. Granted, there's redundancy in having the commented line and the uncommented line (if I understand the defaults correctly), but it might be useful redundancy. Users would have easy reference to what the "factory settings" are. Michael Glaesemann grzm myrealbox com
В списке pgsql-hackers по дате отправления: