Re: postgresql.auto.conf read from wrong directory
От | Fujii Masao |
---|---|
Тема | Re: postgresql.auto.conf read from wrong directory |
Дата | |
Msg-id | CAHGQGwH74ZC7ava5502MCZ2jAvPM3WGUQA3auHLf5xcbsAHrHw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postgresql.auto.conf read from wrong directory (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: postgresql.auto.conf read from wrong directory
|
Список | pgsql-hackers |
On Sat, May 10, 2014 at 12:30 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Fri, May 9, 2014 at 7:01 PM, Fujii Masao <masao.fujii@gmail.com> wrote: >> On Fri, May 9, 2014 at 1:06 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >>> There is no harm in forbidding data_directory, but similarly we can >>> imagine that people can set some very large values for some config >>> variables due to which later it can have symptoms similar to this >>> issue. >> >> Yes, that can prevent the server from restarting at all. In this case, >> to restart the server, we need to edit postgresql.auto.conf manually >> and remove the problematic settings though the header of >> postgresql.auto.conf warns "Do not edit this file manually!". > > So lets not try to forbid data_directory in postgresql.auto.conf and just > fix the case reported in this mail for postgresql.conf for which the > patch is attached upthread. ISTM that data_directory is in different situation from the other. That is, setting data_directory in postgresql.auto.conf is problematic whether its setting value is valid or invalid. Imagine the case where data_directory is set to '/data1' and '/data2' in config_directory/postgresql.conf and /data1/postgresql.auto.conf, respectively. In this case, firstly the server doesn't read /data2/postgresql.auto.conf when it starts up, even if your patch has been applied. Secondly, the server doesn't read /data1/postgresql.auto.conf when it receives SIGHUP, and this causes the following error. LOG: parameter "data_directory" cannot be changed without restarting the server Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: