Re: New horology failure - Mailing list pgsql-hackers

From Tom Lane
Subject Re: New horology failure
Date
Msg-id 16844.1085452153@sss.pgh.pa.us
Whole thread Raw
In response to Re: New horology failure  ("Magnus Hagander" <mha@sollentuna.net>)
Responses Re: New horology failure  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: New horology failure  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
"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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Oliver Jowett
Date:
Subject: log_statement and Parse/Bind
Next
From: Bruce Momjian
Date:
Subject: Re: log_statement and Parse/Bind