Re: New horology failure

Tom Lane wrote:
> "Magnus Hagander" <mha@sollentuna.net> writes:
> >>> I get this since Tom's commit.
> 
> Ah-hah.  It fails if you do "make check" and have not got any
> installation at the configured place, *and* the configured place
> isn't under someplace like /home/postgres.  The reason is that
> relative_path doesn't work.  On my test system, configured
> with --prefix = '/home/tgl/testversion', we end up with
> 
>     PGBINDIR = '/home/tgl/testversion/bin'
>     PGSHAREDIR = '/home/tgl/testversion/share/postgresql'
> 
> because Makefile.global attaches /postgresql to PGSHAREDIR.
> The discrepancy in path length causes relative_path to
> return false ... and even if it returned true, get_share_path
> would do the wrong thing, because it assumes it need only append
> /share after stripping /bin.
> 
> The reason this only affects timezone is that there isn't anything
> else in /share that the backend needs to access.  However I'm not quite
> sure why get_pkglib_path seems not to be having the same confusion...
> 
> In short the "relative path" stuff still needs a lot more work.

Well, in the case you have an install prefix of /usr, we wouldn't want
relative installs because you would have /usr/bin and
/usr/lib/postgresql and that wouldn't be relocatable.

I think the weird part is appending /postgresql on any install that
doesn't already have a pgsql/postgresql in the directory path.  That is
pretty weird, and doesn't interact well with the relocation code.

However, I can't think of a good way to clean that up.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073