Skip site navigation (1) Skip section navigation (2)

Re: Call for porting reports

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Postgres Hackers List <hackers(at)postgresql(dot)org>
Subject: Re: Call for porting reports
Date: 2000-04-02 21:51:00
Message-ID: 8604.954712260@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I am now reproduceably getting this failure in the timestamp test. I have
> never seen it before today:

Is today DST changeover where you live?

The time-related tests have always failed near DST boundaries; the
queries you mention effectively assume that the difference between
successive midnights is exactly 24 hours, which is wrong for DST days.

> The catch is that this *always* happens in the (parallel) regression tests
> but not if I run the file through psql by hand. Gives me a warm feeling
> ... :(

Ah.  The parallel tests set up the postmaster's timezone to be PST8PDT.
Today is DST changeover in that zone, even if it isn't where you live.

> Furthermore, PostgreSQL doesn't compile with gcc 2.8.1 (never has). I get
> a fatal signal if backend/utils/adt/float.c is compiled with -O2 or
> higher. The offending line is in function

> float64 dpow(float64 arg1, float64 arg2)

> *result = (float64data) pow(tmp1, tmp2);

> Certainly a compiler bug, does anyone have a suggestion how this should be
> handled? Is gcc 2.8.1 in wide-spread use?

Write it off as a broken compiler.  Compiler segfaults on valid code are
not our problem.  (As far as I know, the 2.8 series of gcc releases were
never robust enough for production use.  Try 2.95.2 instead.)

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Thomas LockhartDate: 2000-04-02 21:54:26
Subject: Re: 7.0 release notes should call out incompatible changesmore clearly
Previous:From: Thomas LockhartDate: 2000-04-02 21:50:41
Subject: Re: Docs refreshed

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group