Re: New horology failure

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: New horology failure
Дата
Msg-id 16844.1085452153@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: New horology failure  ("Magnus Hagander" <mha@sollentuna.net>)
Ответы Re: New horology failure
Re: New horology failure
Список 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 по дате отправления:

Предыдущее
От: Oliver Jowett
Дата:
Сообщение: log_statement and Parse/Bind
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: log_statement and Parse/Bind