On Wed, May 7, 2014 at 4:57 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Tue, May 6, 2014 at 7:04 PM, Christoph Berg <c...@df7cb.de> wrote: >> Hi, >> >> if you split configuration and data by setting data_directory, >> postgresql.auto.conf is writen to the data directory >> (/var/lib/postgresql/9.4/main in Debian), but tried to be read from >> the etc directory (/etc/postgresql/9.4/main). >> >> One place to fix it would be in ProcessConfigFile in >> src/backend/utils/misc/guc-file.l:162 by always setting >> CallingFileName = NULL in src/backend/utils/misc/guc-file.l:162, but >> that breaks later in AbsoluteConfigLocation() when data_directory is >> NULL. (As the comment in ProcessConfigFile says.) > > This problem occurs because we don't have the value of data_directory > set in postgresql.conf by the time we want to parse .auto.conf file > during server start. The value of data_directory is only available after > processing of config files. To fix it, we need to store the value of > data_directory during parse of postgresql.conf file so that we can use it > till data_directory is actually set. Attached patch fixes the problem. > Could you please once confirm if it fixes the problem in your > env./scenario.
Maybe this is nitpicking, but what happens when postgresql.auto.conf also includes the setting of data_directory? This is possible because we can set data_directory via ALTER SYSTEM now. Should we just ignore such problematic setting in postgresql.auto.conf with warning message? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
