Amit Kapila <amit.kapil...@gmail.com> writes: > 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.
Aside from being about as ugly as it could possibly be, this is wrong, because it only covers one of the possible sources of a data_directory that's different from the config file location. In particular, it's possible to set --config_file=something on the postmaster command line and also set a data directory different than that via -D or a PGDATA environment variable, rather than an entry in postgresql.conf (see the initial logic in SelectConfigFiles). While it's possible that you could deal with that with some even uglier variant on this patch (perhaps involving making SelectConfigFiles export its internal value of configdir), I think that having ProcessConfigFile understand exactly what SelectConfigFiles is going to do to select the final value of data_directory would be a clear modularity violation, and very fragile as well. I think what probably has to happen is that ProcessConfigFile shouldn't be internally responsible for reading the auto file at all, but that we do that via two separate calls to ProcessConfigFile, one for the main file and then one for the auto file; and during initial startup, SelectConfigFiles doesn't make the call for the auto file until after it's established the final value of data_directory. (And by the by, I think that DataDir not data_directory is what to be using to compute the auto file's path.) It's distressing that this wasn't noticed till now; it shows that nobody tested ALTER SYSTEM with a config file outside the data directory, which seems like a rather fundamental omission for any work with GUC files. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers