From: | "BRUSSER Michael" <Michael(dot)BRUSSER(at)3ds(dot)com> |
---|---|
To: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: initdb failure with Postgres 8.4.4 |
Date: | 2010-12-13 15:34:49 |
Message-ID: | 29EA9BFEF7E7FC4F988818CA0C5C78C205A92F@AG-DCC-MBX03.dsone.3ds.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 10, 2010 at 10:54 AM, Andrew Dunstan <andrew(at)dunslane(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-12-13 15:34:50 | Re: proposal : cross-column stats |
Previous Message | Pavel Stehule | 2010-12-13 15:33:27 | Re: hstores in pl/python |