Re: New horology failure

>>I get this since Tom's commit.
>
>>--- ./results/horology.out Sun May 23 11:39:49 2004
>>***************
>>*** 1787,1796 ****
>>! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years
> | Fri Sep 22 18:19:20 1967 PDT
>>[...]
>>--- 1787,1796 ----
>>! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years
> | Fri Sep 22 18:19:20 1967 PST
>>[...]
>
>I got the same with snapshot-20040521 yesterday [i.e. 2004-05-22]
>afternoon when I ran make check. But only once. make installcheck
>passed all tests, and the failure didn't reappear when I tried make
>check again.
>
>I just got the failure again with make check after having configured
>with a new install directory. My guess is that horology needs some
>datafile from the install location.

Not only a file, but the entire directory "<pginstall>/share/timezone",
with subdirs.

Without it, it will parse "PST8PDT" using the default DST rules. If it
finds the file (named PST8PDT in that directory), it will use the
correct DST rules.

//Magnus

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
>> I just got the failure again with make check after having configured
>> with a new install directory. My guess is that horology needs some
>> datafile from the install location.

> Not only a file, but the entire directory "<pginstall>/share/timezone",
> with subdirs.

Hmm, maybe the problem is that the tz files aren't installed into the
right place during "make check"? Or the temp postmaster fails to look
in the right place?

regards, tom lane

"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.

regards, tom lane

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

I said:
> 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...

Actually, get_pkglib_path is wrong too. But the regression tests do not
exercise it. There are two places that probably *should* exercise it:
the creation of the character set conversion functions during initdb and
the creation of the plpgsql call handler function. In normal situations
I'd expect both of these to be relative to $libdir (hence pkglib_path).
But the regression test script carefully overrides that. Maybe we
should consider taking out the override --- it wouldn't be needed
anymore if the relative-path stuff were doing its thing correctly.

regards, tom lane

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> 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.

Why not?

ISTM that the algorithm should go something like this:

1. Take PGBINDIR and strip off the last component (presumably "bin").

2. See if this matches the configured SHAREDIR, PKGLIBDIR, or whatever
*for as many components as are in the stripped BINDIR*. Do not
assume that SHAREDIR must have the same number of components.

3. If match, then what you should do is use the remaining unmatched
part of SHAREDIR etc as what to append to the trimmed exec_path.

For example given the test situation I had:

PGBINDIR = '/home/tgl/testversion/bin'
PGSHAREDIR = '/home/tgl/testversion/share/postgresql'
my_exec_path = '/home/tgl/pgsql-list/src/test/regress/./tmp_check/install//home/tgl/testversion/bin/postmaster'
ret_path = '/home/tgl/testversion/share/postgresql'

what *should* have happened was compare /home/tgl/testversion to
/home/tgl/testversion, decide they agree, and extract share/postgresql
as the part to attach to my_exec_path. Then you'd strip two components
from my_exec_path ("bin" and program name) and attach
"share/postgresql". Voila ... right answer.

regards, tom lane

OK, I will work on that. With everything now centralized it should be
easier.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > 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.
>
> Why not?
>
> ISTM that the algorithm should go something like this:
>
> 1. Take PGBINDIR and strip off the last component (presumably "bin").
>
> 2. See if this matches the configured SHAREDIR, PKGLIBDIR, or whatever
> *for as many components as are in the stripped BINDIR*. Do not
> assume that SHAREDIR must have the same number of components.
>
> 3. If match, then what you should do is use the remaining unmatched
> part of SHAREDIR etc as what to append to the trimmed exec_path.
>
> For example given the test situation I had:
>
> PGBINDIR = '/home/tgl/testversion/bin'
> PGSHAREDIR = '/home/tgl/testversion/share/postgresql'
> my_exec_path = '/home/tgl/pgsql-list/src/test/regress/./tmp_check/install//home/tgl/testversion/bin/postmaster'
> ret_path = '/home/tgl/testversion/share/postgresql'
>
> what *should* have happened was compare /home/tgl/testversion to
> /home/tgl/testversion, decide they agree, and extract share/postgresql
> as the part to attach to my_exec_path. Then you'd strip two components
> from my_exec_path ("bin" and program name) and attach
> "share/postgresql". Voila ... right answer.
>
> regards, tom lane
>

--
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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > 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.
>
> Why not?
>
> ISTM that the algorithm should go something like this:
>
> 1. Take PGBINDIR and strip off the last component (presumably "bin").
>
> 2. See if this matches the configured SHAREDIR, PKGLIBDIR, or whatever
> *for as many components as are in the stripped BINDIR*. Do not
> assume that SHAREDIR must have the same number of components.
>
> 3. If match, then what you should do is use the remaining unmatched
> part of SHAREDIR etc as what to append to the trimmed exec_path.
>
> For example given the test situation I had:
>
> PGBINDIR = '/home/tgl/testversion/bin'
> PGSHAREDIR = '/home/tgl/testversion/share/postgresql'
> my_exec_path = '/home/tgl/pgsql-list/src/test/regress/./tmp_check/install//home/tgl/testversion/bin/postmaster'
> ret_path = '/home/tgl/testversion/share/postgresql'
>
> what *should* have happened was compare /home/tgl/testversion to
> /home/tgl/testversion, decide they agree, and extract share/postgresql
> as the part to attach to my_exec_path. Then you'd strip two components
> from my_exec_path ("bin" and program name) and attach
> "share/postgresql". Voila ... right answer.

OK, I have committed this change. Please let me know if it doesn't work
the way you wanted.

--
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