On Fri, Dec 10, 2010 at 10:54 AM, Andrew Dunstan <and...@dunslane.net> wrote:
> Here's my understanding.
>
> It's not initdb that's really complaining. The timezone files are not inputs
> to initdb. It's the postgres that initdb invokes that's complaining.
>> Postges will look for the share file in two places: the configured install
>> directory or a share directory whose path is calculated relative to its own
>> location
>.initdb's -L flag doesn't override that, it only overrides where
> initdb itself looks for files (such as the BKI file). The bottom line I
> think is that if you intend to use a non-standard layout you need to specify
> the paths for everything and then not move them after installation. If you
> want the installation to be movable, just specify --prefix, but then if you
> move it you have to move the whole thing together. You can't just relocate
> one directory and expect it to work. It won't.
I'm not sure if our current approach would work with v8.4. This is what we do
in the nutshell:
- build Postgres
- do not run install
- collect all generated libraries, executables and input files and pack them
along with other app
- distribute the tar-ball to the customer
- untar and install the app
the installation script at some point calls initdb, create database,
createlang, create user,
it creates config files... done.
I guess this eliminates option 1 - using "the configured install directory"
I tried to figure out the second option "share directory whose path is
calculated relative to its own location"
and ran initdb with "strace". Chances are I overlooked something, but I only
saw Postgres trying to open the
timezone files in the original build path.
Do you see some way to support remote deployment with the approach I described?
Thanks,
Michael.
This email and any attachments are intended solely for the use of the
individual or entity to whom it is addressed and may be confidential and/or
privileged. If you are not one of the named recipients or have received this
email in error, (i) you should not read, disclose, or copy it, (ii) please
notify sender of your receipt by reply email and delete this email and all
attachments, (iii) Dassault Systemes does not accept or assume any liability or
responsibility for any use of or reliance on this email.For other languages, go
to http://www.3ds.com/terms/email-disclaimer.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
