Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-13 Thread Tom Lane
Andrew Dunstan 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 probl

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-13 Thread Andrew Dunstan
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

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-13 Thread BRUSSER Michael
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 machi

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-13 Thread Tom Lane
"BRUSSER Michael" 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

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-13 Thread Alvaro Herrera
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 >

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-13 Thread BRUSSER Michael
On Fri, Dec 10, 2010 at 10:54 AM, Andrew Dunstan 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 con

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread BRUSSER Michael
On 12/10/2010 11:19 AM, Tom Lane wrote: > Robert Haas 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 m

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread Andrew Dunstan
On 12/10/2010 11:19 AM, Tom Lane wrote: Robert Haas 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

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread Tom Lane
Robert Haas 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 >

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread Robert Haas
On Fri, Dec 10, 2010 at 10:54 AM, Andrew Dunstan 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. > Po

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread Andrew Dunstan
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 abs

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread BRUSSER Michael
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/Linux/qe_x86_64' '--without-readline' '--without-zlib' Still:

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread Andrew Dunstan
On 12/10/2010 09:55 AM, Robert Haas wrote: On Fri, Dec 10, 2010 at 9:00 AM, BRUSSER Michael 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

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread Robert Haas
On Fri, Dec 10, 2010 at 9:00 AM, BRUSSER Michael 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 n

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread BRUSSER Michael
>> >> In log2 I got the same errors as I mentioned earlier: >> LOG: could not open directory "/home//.../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

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread Andrew Dunstan
On 12/10/2010 07:32 AM, Robert Haas wrote: On Fri, Dec 10, 2010 at 4:08 AM, BRUSSER Michael wrote: - initdb: initdb -D /home//pgdata -L /home//share -E UTF8 --locale=C \ -d 2> log2> log1 log1 ends with line creating template1 database in /home//pgdata/base/1 ... In log2 I go

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread Robert Haas
On Fri, Dec 10, 2010 at 4:08 AM, BRUSSER Michael wrote: > - initdb: > initdb  -D  /home//pgdata   -L   /home//share -E UTF8 > --locale=C  \ >  -d  2> log2  > log1 > > log1 ends with line >  creating template1 database in /home//pgdata/base/1 ... > > In log2 I got the same errors as I mentioned ea

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-10 Thread BRUSSER Michael
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 co

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-09 Thread Andrew Dunstan
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 d

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-09 Thread BRUSSER Michael
of pg_config if it helps, or try to run initdb with truss or strace. Thanks, Michael. -Original Message- From: Tom Lane [mailto:t...@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

Re: [HACKERS] initdb failure with Postgres 8.4.4

2010-12-09 Thread Tom Lane
"BRUSSER Michael" 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-tzd

[HACKERS] initdb failure with Postgres 8.4.4

2010-12-09 Thread BRUSSER Michael
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 LOG: could not open directory .../install/share/timezone": No such file or directory WARNING: could not open directory .../