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
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
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
[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
>>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
"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
"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.
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
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
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
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
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
12 matches
Mail list logo