From: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | "Mr(dot) Aaron W(dot) Swenson" <titanofold(at)gentoo(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_upgrade - add config directory setting |
Date: | 2011-09-29 16:55:54 |
Message-ID: | 4E84A31A.4020601@pinpointresearch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Cheers,
Steve
From | Date | Subject | |
---|---|---|---|
Next Message | Marios Vodas | 2011-09-29 17:30:22 | Re: Temporary tables and in-memory use |
Previous Message | Tom Lane | 2011-09-29 16:55:29 | Re: Temporary tables and in-memory use |