Thread: New horology failure
I get this since Tom's commit.
Chris
--- ./results/horology.out Sun May 23 11:39:49 2004
***************
*** 1787,1796 ****
| Wed Mar 15 13:14:02 2000 PST | @ 34 years | Tue Mar 15 13:14:02 1966 PST
| Sun Dec 31 17:32:01 2000 PST | @ 34 years | Sat Dec 31 17:32:01 1966 PST
| Mon Jan 01 17:32:01 2001 PST | @ 34 years | Sun Jan 01 17:32:01 1967 PST
! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years | Fri Sep 22 18:19:20 1967 PDT
! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours | Thu Jul 31 12:00:00 1969 PDT
! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons | Fri Aug 01 00:00:00 1969 PDT
! | Thu Jan 01 00:00:00 1970 PST | @ 3 mons | Wed Oct 01 00:00:00 1969 PDT
| Thu Jan 01 00:00:00 1970 PST | @ 10 days | Mon Dec 22 00:00:00 1969 PST
| Thu Jan 01 00:00:00 1970 PST | @ 1 day 2 hours 3 mins 4 secs | Tue Dec 30 21:56:56 1969 PST
| Thu Jan 01 00:00:00 1970 PST | @ 5 hours | Wed Dec 31 19:00:00 1969 PST
--- 1787,1796 ----
| Wed Mar 15 13:14:02 2000 PST | @ 34 years | Tue Mar 15 13:14:02 1966 PST
| Sun Dec 31 17:32:01 2000 PST | @ 34 years | Sat Dec 31 17:32:01 1966 PST
| Mon Jan 01 17:32:01 2001 PST | @ 34 years | Sun Jan 01 17:32:01 1967 PST
! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years | Fri Sep 22 18:19:20 1967 PST
! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours | Thu Jul 31 12:00:00 1969 PST
! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons | Fri Aug 01 00:00:00 1969 PST
! | Thu Jan 01 00:00:00 1970 PST | @ 3 mons | Wed Oct 01 00:00:00 1969 PST
| Thu Jan 01 00:00:00 1970 PST | @ 10 days | Mon Dec 22 00:00:00 1969 PST
| Thu Jan 01 00:00:00 1970 PST | @ 1 day 2 hours 3 mins 4 secs | Tue Dec 30 21:56:56 1969 PST
| Thu Jan 01 00:00:00 1970 PST | @ 5 hours | Wed Dec 31 19:00:00 1969 PST
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> I get this since Tom's commit.
On what platform? How is type time_t defined on your platform?
regards, tom lane
>>I get this since Tom's commit. > > > On what platform? How is type time_t defined on your platform? Hmmm, I just CVS up'd and all regression tests now pass... Chris
[resending...] On Sun, 23 May 2004 11:38:51 +0800, Christopher Kings-Lynne <chriskl@familyhealth.com.au> wrote: >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. ServusManfred
>>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@sollentuna.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@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
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
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
Bruce Momjian <pgman@candle.pha.pa.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
trimmedexec_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@candle.pha.pa.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@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
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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@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