Re: New horology failure

Tom Lane wrote:
> "Magnus Hagander" <mha(at)sollentuna(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073