Re: [HACKERS] New horology failure

2004-05-25 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 shoul

Re: [HACKERS] New horology failure

2004-05-24 Thread Bruce Momjian
OK, I will work on that. With everything now centralized it should be easier. --- Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Well, in the case you have an install prefix of /usr, we wouldn't want > > re

Re: [HACKERS] New horology failure

2004-05-24 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> 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. Ta

Re: [HACKERS] New horology failure

2004-05-24 Thread 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 ex

Re: [HACKERS] New horology failure

2004-05-24 Thread Bruce Momjian
Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> 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

Re: [HACKERS] New horology failure

2004-05-24 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> 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.

Re: [HACKERS] New horology failure

2004-05-24 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> 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 "/share/timezone", > with

Re: [HACKERS] New horology failure

2004-05-24 Thread Magnus Hagander
>>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 2

Re: [HACKERS] New horology failure

2004-05-24 Thread Manfred Koizar
[resending...] On Sun, 23 May 2004 11:38:51 +0800, Christopher Kings-Lynne <[EMAIL PROTECTED]> 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

Re: [HACKERS] New horology failure

2004-05-23 Thread Christopher Kings-Lynne
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] New horology failure

2004-05-23 Thread Tom Lane
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > I get this since Tom's commit. On what platform? How is type time_t defined on your platform? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading throug

[HACKERS] New horology failure

2004-05-22 Thread Christopher Kings-Lynne
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