Re: initdb failure with Postgres 8.4.4

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: BRUSSER Michael <Michael(dot)BRUSSER(at)3ds(dot)com>, 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-10 15:54:39
Message-ID: 4D024D3F.7030909@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-12-10 16:07:46 Re: initdb failure with Postgres 8.4.4
Previous Message Dimitri Fontaine 2010-12-10 15:46:48 Re: Extensions, patch v16