Thread: initdb failure with Postgres 8.4.4
<div class="WordSection1"><p class="MsoNormal">Initdb fails for me when host machine has no access to the Postgres buildlocation.<p class="MsoNormal"> <p class="MsoNormal"><span style="font-family:"Courier New"">LOG: could not open directory.../install/share/timezone": No such file or directory</span><p class="MsoNormal"><span style="font-family:"CourierNew"">LOG: could not open directory .../install/share/timezone": No such file or directory</span><pclass="MsoNormal"><span style="font-family:"Courier New"">WARNING: could not open directory .../install/share/timezonesets":No such file or directory</span><p class="MsoNormal"><span style="font-family:"Courier New"">HINT: This may indicate an incomplete PostgreSQL installation, </span><p class="MsoNormal"><span style="font-family:"CourierNew""> or that the file .../bin.Linux/postgres" has been moved away from its proper location.</span><pclass="MsoNormal"><span style="font-family:"Courier New"">FATAL: invalid value for parameter "timezone_abbreviations":"Default"</span><p class="MsoNormal"><span style="font-family:"Courier New"">DEBUG: shmem_exit(1):0 callbacks to make</span><p class="MsoNormal"><span style="font-family:"Courier New"">DEBUG: proc_exit(1):0 callbacks to make</span><p class="MsoNormal"><span style="font-family:"Courier New"">DEBUG: exit(1)</span><pclass="MsoNormal"><span style="font-family:"Courier New""> </span><p class="MsoNormal">The postgres executableis in the proper place.<p class="MsoNormal">The truncated paths .../install/share/timezone, etc point to the originalbuild location.<p class="MsoNormal"><span style="font-family:"Courier New""> </span><p class="MsoNormal">The timezoneand other files are available in the local directory:<span style="font-family:"Courier New""></span><p class="MsoNormal"><spanstyle="font-family:"Courier New"">share % ls -1</span><p class="MsoNormal"><span style="font-family:"CourierNew"">conversion_create.sql</span><p class="MsoNormal"><span style="font-family:"Courier New"">information_schema.sql</span><pclass="MsoNormal"><span style="font-family:"Courier New"">pg_hba.conf.sample</span><pclass="MsoNormal"><span style="font-family:"Courier New"">pg_ident.conf.sample</span><pclass="MsoNormal"><span style="font-family:"Courier New"">pg_service.conf.sample</span><pclass="MsoNormal"><span style="font-family:"Courier New"">postgres.bki</span><p class="MsoNormal"><spanstyle="font-family:"Courier New"">postgres.description</span><p class="MsoNormal"><span style="font-family:"CourierNew"">postgresql.conf.sample</span><p class="MsoNormal"><span style="font-family:"Courier New"">postgres.shdescription</span><pclass="MsoNormal"><span style="font-family:"Courier New"">psqlrc.sample</span><p class="MsoNormal"><spanstyle="font-family:"Courier New"">recovery.conf.sample</span><p class="MsoNormal"><span style="font-family:"CourierNew"">snowball_create.sql</span><p class="MsoNormal"><span style="font-family:"Courier New"">sql_features.txt</span><pclass="MsoNormal"><span style="font-family:"Courier New"">system_views.sql</span><p class="MsoNormal"><spanstyle="font-family:"Courier New"">timezone</span><p class="MsoNormal"><span style="font-family:"CourierNew"">timezonesets</span><p class="MsoNormal"><span style="font-family:"Courier New"">tsearch_data</span><pclass="MsoNormal"><span style="font-family:"Courier New""> </span><p class="MsoNormal">I callinitdb with the –L option pointing to that directory, from initdb log I can see that it is indeed being used for certainthings –<p class="MsoNormal"> <p class="MsoNormal"><span style="font-family:"Courier New"">POSTGRES_BKI=.../share/postgres.bki</span><pclass="MsoNormal"><span style="font-family:"Courier New"">POSTGRES_DESCR=.../share/postgres.description</span><pclass="MsoNormal"><span style="font-family:"Courier New"">POSTGRES_SHDESCR=.../share/postgres.shdescription</span><pclass="MsoNormal"><span style="font-family:"Courier New"">POSTGRESQL_CONF_SAMPLE=.../share/postgresql.conf.sample</span><pclass="MsoNormal"><span style="font-family:"CourierNew"">PG_HBA_SAMPLE=.../share/pg_hba.conf.sample</span><p class="MsoNormal"><span style="font-family:"CourierNew"">PG_IDENT_SAMPLE=.../share/pg_ident.conf.sample</span><p class="MsoNormal"><span style="font-family:"CourierNew""> </span><p class="MsoNormal">I am wondering why the timezone files cannot be found thereas well?<p class="MsoNormal">This is quite urgent and any help will be greatly appreciated.<p class="MsoNormal">Michael.<pclass="MsoNormal">.<p class="MsoNormal"><br /><br /></div><p style="FONT-SIZE: 9pt; MARGIN: 0px0px 0px 35.4pt; COLOR: #1f497d; FONT-STYLE: italic; FONT-FAMILY: Arial, Helvetica, sans-serif">This email and any attachmentsare intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/orprivileged.<p style="FONT-SIZE: 9pt; MARGIN: 0px 0px 0px 35.4pt; COLOR: #1f497d; FONT-STYLE: italic; FONT-FAMILY: Arial,Helvetica, sans-serif">If you are not one of the named recipients or have received this email in error, <p style="FONT-SIZE:9pt; MARGIN: 0px 0px 0px 35.4pt; COLOR: #1f497d; FONT-STYLE: italic; FONT-FAMILY: Arial, Helvetica, sans-serif">(i)you should not read, disclose, or copy it,<p style="FONT-SIZE: 9pt; MARGIN: 0px 0px 0px 35.4pt; COLOR: #1f497d;FONT-STYLE: italic; FONT-FAMILY: Arial, Helvetica, sans-serif">(ii) please notify sender of your receipt by replyemail and delete this email and all attachments,<p style="FONT-SIZE: 9pt; MARGIN: 0px 0px 0px 35.4pt; COLOR: #1f497d;FONT-STYLE: italic; FONT-FAMILY: Arial, Helvetica, sans-serif">(iii) Dassault Systemes does not accept or assumeany liability or responsibility for any use of or reliance on this email.<p style="FONT-STYLE: italic; MARGIN: 0px0px 0px 35.4pt; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #1f497d; FONT-SIZE: 9pt"><p style="FONT-SIZE: 9pt; MARGIN:0px 0px 0px 35.4pt; COLOR: #1f497d; FONT-STYLE: italic; FONT-FAMILY: Arial, Helvetica, sans-serif">For other languages,<a href="http://www.3ds.com/terms/email-disclaimer">Click Here</a>
"BRUSSER Michael" <Michael.BRUSSER@3ds.com> writes:
> Initdb fails for me when host machine has no access to the Postgres build location.
> LOG: could not open directory .../install/share/timezone": No such file or directory
Moving the install tree works for me. Did you do something odd with the
--with-system-tzdata configuration option?
regards, tom lane
No, we do not use --with-system-tzdata option.
I looked at the makefile and at the output of pg_config. We may need to do some cleanup there, but I did not pick any
clues.
The problem occurs on all our UNIX platforms.
Is there anything I could do to shed more light on it?
I can post the output of pg_config if it helps, or try to run initdb with truss or strace.
Thanks,
Michael.
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, December 09, 2010 2:56 PM
To: BRUSSER Michael
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] initdb failure with Postgres 8.4.4
"BRUSSER Michael" <Michael.BRUSSER@3ds.com> writes:
> Initdb fails for me when host machine has no access to the Postgres build location.
> LOG: could not open directory .../install/share/timezone": No such file or directory
Moving the install tree works for me. Did you do something odd with the
--with-system-tzdata configuration option?
regards, tom lane
This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and
maybe 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
emailand all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use
ofor reliance on this email.For other languages, go to http://www.3ds.com/terms/email-disclaimer.
On 12/09/2010 03:36 PM, BRUSSER Michael wrote: > No, we do not use --with-system-tzdata option. > I looked at the makefile and at the output of pg_config. We may need to do some cleanup there, but I did not pick any clues. > The problem occurs on all our UNIX platforms. > Is there anything I could do to shed more light on it? > I can post the output of pg_config if it helps, or try to run initdb with truss or strace. > Yes, please show us the pg_config (and please don't top-post). cheers andrew
On 12/09/2010 03:36 PM, BRUSSER Michael wrote: > No, we do not use --with-system-tzdata option. > I looked at the makefile and at the output of pg_config. We may need to do some cleanup there, but I did not pick any clues. > The problem occurs on all our UNIX platforms. > Is there anything I could do to shed more light on it? > I can post the output of pg_config if it helps, or try to run initdb with truss or strace. > Yes, please show us the pg_config (and please don't top-post). cheers andrew --------------------------------------------------------------------------------------------------- I tried to build Postgres with minimal options outside of our normal build framework to isolate possible interference, butgot the same result. configure \ --prefix=$prefix \ --without-readline \ --without-zlib \ --without-tcl \ --without-perl \ --disable-rpath \ 2>&1 | tee _configure.log - gmake, gmake check, gmake install -- all clean - initdb: initdb -D /home/<local_path>/pgdata -L /home/<local_path>/share -E UTF8 --locale=C \-d 2> log2 > log1 log1 ends with line creating template1 database in /home/<local_path>/pgdata/base/1 ... In log2 I got the same errors as I mentioned earlier: LOG: could not open directory "/home/<build-path>/.../share/timezone":No such file or directory ... ... Directories timezone and timezonesets exist in /home/<local_path>/share, pointed to by the -L option The local share dir has the same contents as the build share dir. % pg_config BINDIR = /home/<build-path>/build/Linux/qe_x86_64/binDOCDIR = /home/<build-path>/build/Linux/qe_x86_64/share/docHTMLDIR= /home/<build-path>/build/Linux/qe_x86_64/share/docINCLUDEDIR =/home/<build-path>/build/Linux/qe_x86_64/includePKGINCLUDEDIR = /home/<build-path>/build/Linux/qe_x86_64/includeINCLUDEDIR-SERVER= /home/<build-path>/build/Linux/qe_x86_64/include/serverLIBDIR= /home/<build-path>/build/Linux/qe_x86_64/libPKGLIBDIR = /home/<build-path>/build/Linux/qe_x86_64/libLOCALEDIR= /home/<build-path>/build/Linux/qe_x86_64/share/localeMANDIR = /home/<build-path>/build/Linux/qe_x86_64/share/manSHAREDIR= /home/<build-path>/build/Linux/qe_x86_64/shareSYSCONFDIR = /home/<build-path>/build/Linux/qe_x86_64/etcPGXS= /home/<build-path>/build/Linux/qe_x86_64/lib/pgxs/src/makefiles/pgxs.mkCONFIGURE= '--prefix=/home/<build-path>/build/Linux/qe_x86_64''--without-readline' '--without-zlib'CC = gccCPPFLAGS = -D_GNU_SOURCECFLAGS= -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing-fwrapvCFLAGS_SL = -fpicLDFLAGS = -Wl,--as-needed -Wl,-rpath,'/home/<build-path>/build/Linux/qe_x86_64/lib'LDFLAGS_SL= LIBS = -lpgport -lcrypt -ldl -lm VERSION = PostgreSQL8.4.4 This is probably not helpful, but just in case % strings initdb | grep <build-path>/home/<build-path>/build/Linux/qe_x86_64/bin/home/<build-path>/build/Linux/qe_x86_64/share/man/home/<build-path>/build/Linux/qe_x86_64/share/doc//home/<build-path>/build/Linux/qe_x86_64/share/locale/home/<build-path>/build/Linux/qe_x86_64/lib/home/<build-path>/build/Linux/qe_x86_64/include/server/home/<build-path>/build/Linux/qe_x86_64/include/home/<build-path>/build/Linux/qe_x86_64/etc/home/<build-path>/build/Linux/qe_x86_64/share Thank you, Michael. This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and maybe 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 emailand all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use ofor reliance on this email.For other languages, go to http://www.3ds.com/terms/email-disclaimer.
On Fri, Dec 10, 2010 at 4:08 AM, BRUSSER Michael <Michael.BRUSSER@3ds.com> wrote: > - initdb: > initdb -D /home/<local_path>/pgdata -L /home/<local_path>/share -E UTF8 --locale=C \ > -d 2> log2 > log1 > > log1 ends with line > creating template1 database in /home/<local_path>/pgdata/base/1 ... > > In log2 I got the same errors as I mentioned earlier: > LOG: could not open directory "/home/<build-path>/.../share/timezone": No such file or directory > ... ... Does it really have a pathname with three dots here? I'd have more confidence we knew what we were looking at if you sent the actual log, rather than an edited version of the lines you think are most important. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 12/10/2010 07:32 AM, Robert Haas wrote: > On Fri, Dec 10, 2010 at 4:08 AM, BRUSSER Michael > <Michael.BRUSSER@3ds.com> wrote: >> - initdb: >> initdb -D /home/<local_path>/pgdata -L /home/<local_path>/share -E UTF8 --locale=C \ >> -d 2> log2> log1 >> >> log1 ends with line >> creating template1 database in /home/<local_path>/pgdata/base/1 ... >> >> In log2 I got the same errors as I mentioned earlier: >> LOG: could not open directory "/home/<build-path>/.../share/timezone": No such file or directory >> ... ... > Does it really have a pathname with three dots here? > > I'd have more confidence we knew what we were looking at if you sent > the actual log, rather than an edited version of the lines you think > are most important. > And why the heck use initdb's -L? initdb knows quite well where to get its files from, if you haven't mucked up the installation. I don't think I've ever seen a case in production where it's been necessary. cheers andrew
>>
>> In log2 I got the same errors as I mentioned earlier:
>> LOG: could not open directory "/home/<build-path>/.../share/timezone": No such file or directory
>> ... ...
> Does it really have a pathname with three dots here?
>
> I'd have more confidence we knew what we were looking at if you sent
> the actual log, rather than an edited version of the lines you think
> are most important.
>
And why the heck use initdb's -L? initdb knows quite well where to get
its files from, if you haven't mucked up the installation. I don't think
I've ever seen a case in production where it's been necessary.
-------------------------------------
1) The pathnames referenced in the log do not have any dots, I just truncated them - they are absolute pathnames to
wherethe timezone files are locates in the source or build tree I'll post the entire log if it is still needed after
this...
2) We have been using 'initdb -L' since Postgres 7.2 The way it works here we build Postgres and it gets bundled as a
partof a larger application, which can be installed anywhere. Perhaps this makes it difficult for initdb to "know
quitewell where to get its files from".
If I remove the -L switch initdb breaks very early before it gets to the timezones: share_path points back to the
buildlocation, which is not available, so it cannot locate postgres.bki and other input files.
The timezones piece seems to be the only problem - if I compile with --with-system-tzdata=/usr/share/zoneinfo
andthen use initdb -L installation succeeds when the source/build tree is not accessible. Not claiming any
knowledgein this area - would it be reasonable to expect that if -L option works for other input files it should
alsowork for timezones?
Thanks for all your help
This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and
maybe 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
emailand all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use
ofor reliance on this email.For other languages, go to http://www.3ds.com/terms/email-disclaimer.
On Fri, Dec 10, 2010 at 9:00 AM, BRUSSER Michael <Michael.BRUSSER@3ds.com> wrote: > 1) The pathnames referenced in the log do not have any dots, I just truncated them - > they are absolute pathnames to where the timezone files are locates in the source or build tree > I'll post the entire log if it is still needed after this ... Well, why are you configuring the prefix to be inside your build tree?This is an odd thing to do. The prefix should be setto where you expect to install the files, not where you're building them. CONFIGURE = '--prefix=/home/<build-path>/build/Linux/qe_x86_64' '--without-readline' '--without-zlib' Still: > Not claiming any knowledge in this area - would it be reasonable to expect that if -L option works for other inputfiles it should > also work for timezones? ...this seems reasonable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 12/10/2010 09:55 AM, Robert Haas wrote: > On Fri, Dec 10, 2010 at 9:00 AM, BRUSSER Michael > <Michael.BRUSSER@3ds.com> wrote: >> 1) The pathnames referenced in the log do not have any dots, I just truncated them - >> they are absolute pathnames to where the timezone files are locates in the source or build tree >> I'll post the entire log if it is still needed after this ... > Well, why are you configuring the prefix to be inside your build tree? > This is an odd thing to do. The prefix should be set to where you > expect to install the files, not where you're building them. > > CONFIGURE = '--prefix=/home/<build-path>/build/Linux/qe_x86_64' > '--without-readline' '--without-zlib' > > Still: > >> Not claiming any knowledge in this area - would it be reasonable to expect that if -L option works for other inputfiles it should >> also work for timezones? > ...this seems reasonable. OK, this has nothing at all to do with the absence of the build path. It has to do with using a non-standard sharedir.I have reproduced it thus: [andrew@aurelia blurflinst]$ mv share/ foo [andrew@aurelia blurflinst]$ bin/initdb -L `pwd`/foo/postgresql data3 Thefiles belonging to this database system will be owned by user "andrew". This user must also own the server process. The database cluster will be initialized with locale en_US.utf8. The default database encoding has accordingly beenset to UTF8. The default text search configuration will be set to "english". creating directory data3 ... ok creating subdirectories ... ok selecting default max_connections ... 10 selectingdefault shared_buffers ... 400kB creating configuration files ... ok creating template1 database in data3/base/1... WARNING: could not open directory "/home/andrew/pgl/blurflinst/share/postgresql/timezonesets": No such file or directory HINT: This may indicate an incomplete PostgreSQL installation, or that the file "/home/andrew/pgl/blurflinst/bin/postgres"has been moved away from its proper location. FATAL: invalid value for parameter"timezone_abbreviations": "Default" child process exited with exit code 1 initdb: removing data directory "data3" [andrew@aurelia blurflinst]$ I will dig a bit further. cheers andrew
Well, why are you configuring the prefix to be inside your build tree?This is an odd thing to do. The prefix should be setto where you expect to install the files, not where you're building them. CONFIGURE = '--prefix=/home/<build-path>/build/Linux/qe_x86_64' '--without-readline' '--without-zlib' Still: > Not claiming any knowledge in this area - would it be reasonable to expect that if -L option works for other inputfiles it should > also work for timezones? ...this seems reasonable. --------------------------------------------------------- It is odd, but this only reflects some quick hack I did to have a test case outside of our standard build framework. I wanted to make sure the odd problem with timezones is not coming from our overloaded build environment. Production makefile does it much better. If I don't find a better option - do you see any disadvantage in using --with-system-tzdata and OS timezone info on Solarisand Linux? This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and maybe 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 emailand all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use ofor reliance on this email.For other languages, go to http://www.3ds.com/terms/email-disclaimer.
On 12/10/2010 10:25 AM, Andrew Dunstan wrote: > > >> >>> Not claiming any knowledge in this area - would it be >>> reasonable to expect that if -L option works for other input files >>> it should >>> also work for timezones? >> ...this seems reasonable. > > > OK, this has nothing at all to do with the absence of the build path. > It has to do with using a non-standard sharedir.I have reproduced it > thus: > > [snip] > I will dig a bit further. > > 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. cheers andrew
On Fri, Dec 10, 2010 at 10:54 AM, Andrew Dunstan <andrew@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. That was my impression, too, from the log that was sent. > 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. So in theory we could have a GUC under "file locations" to override this, similarly to data_directory or hba_file or ident_file. But since it's been like this for a really long time (I think), I wouldn't be inclined to go monkeying with it unless more than one person complains. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> So in theory we could have a GUC under "file locations" to override
> this, similarly to data_directory or hba_file or ident_file. But
> since it's been like this for a really long time (I think), I wouldn't
> be inclined to go monkeying with it unless more than one person
> complains.
Even if we did see more than one request, I'd be inclined not to change
it. The installation layout stuff is too complicated and fragile
already; and AFAICS it does cover every *reasonable* use case.
regards, tom lane
On 12/10/2010 11:19 AM, Tom Lane wrote: > Robert Haas<robertmhaas@gmail.com> writes: >> So in theory we could have a GUC under "file locations" to override >> this, similarly to data_directory or hba_file or ident_file. But >> since it's been like this for a really long time (I think), I wouldn't >> be inclined to go monkeying with it unless more than one person >> complains. > Even if we did see more than one request, I'd be inclined not to change > it. The installation layout stuff is too complicated and fragile > already; and AFAICS it does cover every *reasonable* use case. > > I agree, although I think Robert's "really long time" is in fact "since 8.0, before which we didnt provide for relocation at all." cheers andrew
On 12/10/2010 11:19 AM, Tom Lane wrote: > Robert Haas<robertmhaas@gmail.com> writes: >> So in theory we could have a GUC under "file locations" to override >> this, similarly to data_directory or hba_file or ident_file. But >> since it's been like this for a really long time (I think), I wouldn't >> be inclined to go monkeying with it unless more than one person >> complains. > Even if we did see more than one request, I'd be inclined not to change > it. The installation layout stuff is too complicated and fragile > already; and AFAICS it does cover every *reasonable* use case. > > I agree, although I think Robert's "really long time" is in fact "since 8.0, before which we didnt provide for relocation at all." cheers andrew -------------------------------------- Thanks, everyone!!! I'm still not sure I completely understand how to package all components to allow independent installation, but I guess this is what this weekend is good for :( Michael This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and maybe 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 emailand all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use ofor reliance on this email.For other languages, go to http://www.3ds.com/terms/email-disclaimer.
On Fri, Dec 10, 2010 at 10:54 AM, Andrew Dunstan <andrew@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 maybe 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 emailand all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use ofor reliance on this email.For other languages, go to http://www.3ds.com/terms/email-disclaimer.
Excerpts from BRUSSER Michael's message of lun dic 13 12:34:49 -0300 2010: > 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 think this procedure needs to be fixed. It should be: - build Postgres - install - collect the files, pack - distribute - unpack to the destination directory Since our packaging is (supposed to be) relocatable, you can install in the customer's machine at a different destination directory, and it should work. If it doesn't, report it as a bug. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
"BRUSSER Michael" <Michael.BRUSSER@3ds.com> writes:
> 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.
If that ever worked, with any version of Postgres, I'd be astonished.
Here is what you should do:
1. Build Postgres with --prefix set to some empty directory.
2. Run install.
3. Bundle up the resulting install tree as part of your tarball. Do not
editorialize upon the relative locations of its contents.
4. Drop the install tree wherever you want on the target machine.
regards, tom lane
Here is what you should do: 1. Build Postgres with --prefix set to some empty directory. 2. Run install. 3. Bundle up the resulting install tree as part of your tarball. Do not editorialize upon the relative locations of its contents. 4. Drop the install tree wherever you want on the target machine. ------------------------------------------------- Would it be a completely crazy idea if I try to modify Postgres to look at some env. var (similar to PGDATA) and if exists and path is valid look there for the timezone files? Michael This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and maybe 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 emailand all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use ofor reliance on this email.For other languages, go to http://www.3ds.com/terms/email-disclaimer.
On 12/13/2010 12:16 PM, BRUSSER Michael wrote: > Here is what you should do: > > 1. Build Postgres with --prefix set to some empty directory. > 2. Run install. > 3. Bundle up the resulting install tree as part of your tarball. Do not > editorialize upon the relative locations of its contents. > 4. Drop the install tree wherever you want on the target machine. > > ------------------------------------------------- > > Would it be a completely crazy idea if I try to modify Postgres to look at some env. var > (similar to PGDATA) and if exists and path is valid look there for the timezone files? > Yes, that's only the first problem you have encountered. I predict there will be others if you go down this path. You are making life much harder for yourself than you need to. Just keep everything together and you'll be fine. If that's really impossible, use symlinks (or junction points on Windows) to achieve the same effect. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> On 12/13/2010 12:16 PM, BRUSSER Michael wrote:
>> Would it be a completely crazy idea if I try to modify Postgres to look at some env. var
>> (similar to PGDATA) and if exists and path is valid look there for the timezone files?
> Yes, that's only the first problem you have encountered. I predict there
> will be others if you go down this path.
As far as the timezone data files go, you might have use for the
--with-system-tzdata configure option. Note that that is not an
"environment variable"; it requires a hard coded path to the system
copy of the Olsen timezone database. The expectation is that any
system-maintained copy will have a very well-defined location for
those files on any given platform, so there is no need for runtime
tweaking. You would use this only on platforms where you expect
that normal system maintenance procedures will keep the TZ files more
up-to-date than the ones included with Postgres.
I agree with Andrew's point in general. Trying to customize the
relative layout of the various Postgres-installed files is an
exercise in pointless pain.
regards, tom lane