Re: postgresql.auto.conf read from wrong directory

Amit Kapila <amit(dot)kapila16(at)gmail(dot)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