Thread: Psql 7.2.1 Regress tests failed on RedHat 7.3
I have tried to install postgresql 7.2.1 on the new Red Hat 7.3. The regression test failed in three cases: - abstime - tinterval - horology I have included to the mail the regression.diffs and regression.out files... Is there any reason? Any tip? The machine has two processors with 1Gb of Ram. -- Doct. Eng. Denis Gasparin: denis@edistar.com --------------------------- Programmer & System Administrator - Edistar srl
Attachment
Denis Gasparin <denis@edistar.com> writes:
> Is there any reason? Any tip?
The diffs seem to be in the same places as for Solaris --- perhaps
someone tried to correct 7.3's timezone database for the 1947 DST
rules? (AFAIK, Solaris is more correct for 1947 than most other
timezone databases.) If so, they blew it ...
regards, tom lane
Denis Gasparin <denis@edistar.com> writes: > I have tried to install postgresql 7.2.1 on the new Red Hat 7.3. The > regression test failed in three cases: The tests are buggy in some cases... the expected results are not locale aware (e.g. "12.42" vs "12,42", "A C b" v "A b C") -- Trond Eivind Glomsrød Red Hat, Inc.
I've tried to replace the RH 7.3 timezone database (in /usr/share/zoneinfo) with that of RH 7.2 (where regress tests work). The problem persists... In RH 7.3 there is also a new version of the glibc... (2.2.5 - 34) If anyone has any idea... -- Doct. Eng. Denis Gasparin: denis@edistar.com --------------------------- Programmer & System Administrator - Edistar srl Il gio, 2002-05-09 alle 19:39, Tom Lane ha scritto: > Denis Gasparin <denis@edistar.com> writes: > > Is there any reason? Any tip? > > The diffs seem to be in the same places as for Solaris --- perhaps > someone tried to correct 7.3's timezone database for the 1947 DST > rules? (AFAIK, Solaris is more correct for 1947 than most other > timezone databases.) If so, they blew it ... > > regards, tom lane
> Denis Gasparin <denis@edistar.com> writes:
>
> > I have tried to install postgresql 7.2.1 on the new Red Hat 7.3. The
> > regression test failed in three cases:
>
> The tests are buggy in some cases... the expected results are not
> locale aware (e.g. "12.42" vs "12,42", "A C b" v "A b C")
This isn't the case you've indicated... This is the regression test diff
output:
*** ./expected/abstime.out Wed Nov 21 19:27:25 2001
--- ./results/abstime.out Thu May 9 17:27:00 2002
***************
*** 44,50 ****
| Wed Dec 31 16:00:00 1969 PST
| infinity
| -infinity
! | Sat May 10 23:59:12 1947 PST
| invalid
(7 rows)
--- 44,50 ----
| Wed Dec 31 16:00:00 1969 PST
| infinity
| -infinity
! | Sat May 10 15:59:12 1947 PST
| invalid
(7 rows)
As you can see the time is different not the time/date format...
--
Doct. Eng. Denis Gasparin: denis@edistar.com
---------------------------
Programmer & System Administrator - Edistar srl
...
> This isn't the case you've indicated... This is the regression test diff
> output:
> *** ./expected/abstime.out Wed Nov 21 19:27:25 2001
> --- ./results/abstime.out Thu May 9 17:27:00 2002
> ! | Sat May 10 23:59:12 1947 PST
...
> ! | Sat May 10 15:59:12 1947 PST
...
> As you can see the time is different not the time/date format...
Ooh. Maybe the SuSE folks who were working on glibc actually changed it
the way they were talking about. Here (may be) the issue:
Posix demands that mktime() and friends return -1 on error or on "unable
to convert time". Traditionally, many implementations (AIX was a notable
exception, adding to its rep as a brain-damaged system) ignored that
restriction, willingly converting for times before 1970, and returning a
negative number. And timezone databases supported times before 1970, and
the world was happy.
But that Posix requirement made it difficult to support the time "one
second before 1970", which happens to be "-1". So the idea was to start
returning -1 for any time before 1970. That sucks. But for PostgreSQL,
we actually don't use the results of mktime(), but we *do* use a
side-effect of the call, which fills in the time zone information (and a
few other fields) in the structures given to mktime() as *input*. We
currently ignore the status return of mktime(), since we guard against
illegal calling parameters another way.
I would be very happy if the implementation of mktime() continued to
*properly* fill in these fields, even though it insists on returning an
error condition for dates before 1970. As it is (assuming that a change
actually has occurred) the timezone system in GNU systems has been badly
and gratuitously damaged in the newest releases of glibc.
Any suggestions on how to pursue this??
- Thomas
In article <3CDBD134.15FCF31D@fourpalms.org>,
Thomas Lockhart <lockhart@fourpalms.org> wrote:
>error condition for dates before 1970. As it is (assuming that a change
>actually has occurred) the timezone system in GNU systems has been badly
>and gratuitously damaged in the newest releases of glibc.
The mktime.c for glibc hasn't changed since Jul 5, 2001.
mrc
--
Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
> >error condition for dates before 1970. As it is (assuming that a change
> >actually has occurred) the timezone system in GNU systems has been badly
> >and gratuitously damaged in the newest releases of glibc.
> The mktime.c for glibc hasn't changed since Jul 5, 2001.
There is a thread (I'm pretty sure it was on-list) which points at a
change log which shows that the behavior of mktime() was changed in the
glibc development tree. My recollection might be wrong on details, but I
strongly recall this to be substantially correct.
Hopefully the changes are backed out or at least the "set the time zone"
side effect continues to be supported (it wasn't clear what the actual
change in implementation would do; I didn't look at the source).
Otherwise, Linux systems will look more and more like they were built by
kids who weren't even alive before 1970. Hmm, maybe that's the
explanation... ;)
- Thomas (*definitely* pre-1970)
On Friday 10 May 2002 09:55 am, Thomas Lockhart wrote: > Ooh. Maybe the SuSE folks who were working on glibc actually changed it > the way they were talking about. Here (may be) the issue: > But that Posix requirement made it difficult to support the time "one > second before 1970", which happens to be "-1". So the idea was to start > returning -1 for any time before 1970. That sucks. But for PostgreSQL, > we actually don't use the results of mktime(), but we *do* use a > side-effect of the call, which fills in the time zone information (and a > few other fields) in the structures given to mktime() as *input*. We > currently ignore the status return of mktime(), since we guard against > illegal calling parameters another way. > I would be very happy if the implementation of mktime() continued to > *properly* fill in these fields, even though it insists on returning an > error condition for dates before 1970. As it is (assuming that a change > actually has occurred) the timezone system in GNU systems has been badly > and gratuitously damaged in the newest releases of glibc. Well, I went to bat for this a little bit ago, relating to a bug report, but I've struck out. The ISO C standard spells it out plainly that dates before 1970 are just simply illegal for mktime and friends. So, glibc was aligned with the ISO standard (available online -- see my link in the post regarding the mktime bug in Red Hat 7.3). This will change ALL newer Linux distributions, and thus we need to correct our usage, as the glibc people are not likely to change -- in fact, they will likely say that our code is broken. > Any suggestions on how to pursue this?? What information do we need? Frankly, relying on a side-effect of a call in this way is our bug. Sorry. It was a neat hack, but it now is broken. Where is this in the tree? I can take a look at it if no one else wants to. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> Well, I went to bat for this a little bit ago, relating to a bug report, but
> I've struck out. The ISO C standard spells it out plainly that dates before
> 1970 are just simply illegal for mktime and friends.
Well, since glibc apparently has no higher ambition than to work for
post-1970 dates, we may have little choice but to throw out mktime and
implement our own timezone library. Ugh. It is pretty damn annoying
that they aren't interested in fixing their problem...
regards, tom lane
In article <17682.1021952389@sss.pgh.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Well, since glibc apparently has no higher ambition than to work for
>post-1970 dates, we may have little choice but to throw out mktime and
>implement our own timezone library. Ugh. It is pretty damn annoying
>that they aren't interested in fixing their problem...
Ummm... I'm no great admirer of Drepper, but exactly why is this a glibc
problem?
This was clearly an undocumented side-effect that, by pure chance, worked
well until now. So it happens to be glibc that first trips up this issue,
but it could very well have been any mktime implementation.
I think it's unfair to blame glibc. At least until some other standard
comes into existence that makes glibc's implementation invalid.
mrc
--
Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
dalgoda@ix.netcom.com (Mike Castle) writes:
> I think it's unfair to blame glibc. At least until some other standard
> comes into existence that makes glibc's implementation invalid.
Nonsense. Are you saying it's a mistake that the Linux timezone
databases (and those of most every other Unix, other than maybe AIX)
cover pre-1970 years? The folks who took the trouble to develop
those databases did not think that Unix time began on 1970-01-01.
The glibc guys have decided that they will hew to the letter of a
lowest-common-denominator standard by removing functionality,
namely the ability to do anything with pre-1970 dates.
Since they evidently value a narrow reading of a spec over
functionality, I cannot debate with them. But I think it's a seriously
misguided position. glibc will join AIX as one of only two libc's on
the planet that do not have this functionality. Meanwhile, the Postgres
project will be wasting manpower on reinventing a wheel we shouldn't
have to reinvent.
regards, tom lane