Steve Crawford wrote:
> On 09/29/2011 08:20 AM, Bruce Momjian wrote:
> > ...
> > 1  document the limitation and require users to use symlinks
> > 2  add a --old/new-configdir parameter to pg_upgrade
> > 3  have pg_upgrade find the real data dir by starting the server
> > 4  add a flag to some tool to return the real data dir, and backpatch
> >     that
> 5. (really 3a). Have pg_upgrade itself check the specified --XXX-datadir 
> for postgresql.conf and use the data_directory setting therein using the 
> same rules as followed by the server.
> This would mean that there are no new options to pg_upgrade and that 
> pg_upgrade operation would not change when postgresql.conf is in the 
> data-directory. This would also make it consistent with PostgreSQL's 
> notion of file-locations:
> "If you wish to keep the configuration files elsewhere than the data 
> directory, the postgres -D command-line option or PGDATA environment 
> variable must point to the directory containing the configuration files, 
> and the data_directory parameter must be set in postgresql.conf..."
> So for backporting, it could just be considered a "bug fix" that aligns 
> pg_upgrade's interpretation of datadir to that of the server.

pg_upgrade is not about to start reading through postgresql.conf looking
for a definition for data_directory --- there are too many cases where
this could go wrong.  It would need a full postgresql.conf parser.

  Bruce Momjian  <>

  + It's impossible for everything to be true. +

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to