Re: Options given both on cmd-line and in the config with different values - Mailing list pgsql-hackers

From Honza Horak
Subject Re: Options given both on cmd-line and in the config with different values
Date
Msg-id 2d884859-1455-53bd-7821-c3e776569ac3@redhat.com
Whole thread Raw
In response to Re: Options given both on cmd-line and in the config with different values  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 4/14/21 7:55 PM, Tom Lane wrote:
> Honza Horak <hhorak@redhat.com> writes:
>> I'm trying to understand what is happening in the following bug report:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1935301
> 
>> The upgrade process makes it a bit more difficult, but it seems to boil
>> down to this problem -- even when pg_ctl gets clear guidance where to
>> find datadir using -D option on the command-line, it forgets this
>> guidance once finding data_directory option in the postgresql.conf.
> 
>> Is this the expected behavior actually?
> 
> The rule actually is that -D on the command line says where to find
> the configuration file.  While -D is then also the default for where
> to find the data directory, the config file can override that by
> giving data_directory explicitly.
> 
> This is intended to support situations where the config file is kept
> outside the data directory for management reasons.  If you are not
> actively doing that, I'd recommend *not* setting data_directory
> explicitly in the file.
> 
> While I've not studied the bug report carefully, it sounds like the
> update process you're using involves copying the old config file
> across verbatim.  You'd at minimum need to filter out data_directory
> and related settings to make that safe.

Thanks for explaining, it makes perfect sense. You're right that there 
is some dbdata directory moving involved, so in that case removing 
data_directory option from postgresql.conf makes sense.

Thanks,
Honza




pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Schema variables - new implementation for Postgres 15
Next
From: Tom Lane
Date:
Subject: Re: Replacing pg_depend PIN entries with a fixed range check