Greg Stark writes:
> In looking through the build farm wreckage caused by fsyncing
> directories I noticed this interesting failure on pika:
> + ERROR: role "clstr_user" cannot be dropped because some objects depend on
> it
> + DETAIL: owner of table pg_temp_9.clstr_temp
That was fixed ages a
Le 15 févr. 2010 à 12:52, Greg Stark a écrit :
In looking through the build farm wreckage caused by fsyncing
directories I noticed this interesting failure on pika:
== pgsql.13659/src/test/regress/regression.diffs
===
*** /home/pgbuildfarm/workdir/HEAD/pgsql.136
In looking through the build farm wreckage caused by fsyncing
directories I noticed this interesting failure on pika:
== pgsql.13659/src/test/regress/regression.diffs
===
***
/home/pgbuildfarm/workdir/HEAD/pgsql.13659/src/test/regress/expected/cluster.out
Wed
F
On Tue, 2009-04-14 at 11:16 -0400, Tom Lane wrote:
> > So what changed between 8.3 and 8.4? Same box can build 8.3 with
> > --with-system-tzdata .
>
> We didn't have 64-bit tzdata support before --- it's a new test
> covering new functionality.
Thanks Tom.
Regards,
--
Devrim GÜNDÜZ, RHCE
devr
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
> On Mon, 2009-04-13 at 15:31 -0400, Tom Lane wrote:
>> This test is checking whether you have working 64-bit-tzdata support.
>> It seems you don't.
> So what changed between 8.3 and 8.4? Same box can build 8.3 with
> --with-system-tzdata .
We didn't h
On Mon, 2009-04-13 at 15:31 -0400, Tom Lane wrote:
> > I'm getting the following failure on RHEL 4:
>
> > http://www.gunduz.org/temp/regression.out
> > http://www.gunduz.org/temp/regression.diffs
>
> This test is checking whether you have working 64-bit-tzdata support.
> It seems you don't.
>
>
Hi,
I'm getting the following failure on RHEL 4:
http://www.gunduz.org/temp/regression.out
http://www.gunduz.org/temp/regression.diffs
Here is the Makefile.regress that I use while building RPMs on 8.4:
https://projects.commandprompt.com/public/pgcore/repo/rpm/redhat/8.4/postgresql/EL-4/Makefil
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
> I'm getting the following failure on RHEL 4:
> http://www.gunduz.org/temp/regression.out
> http://www.gunduz.org/temp/regression.diffs
This test is checking whether you have working 64-bit-tzdata support.
It seems you don't.
If you built with --with-
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I'm seeing the following regression failure in PL/Tcl. It seems to be
> > just an ordering issue, and the order in which a trigger is fired.
>
> Works on my x86_64 box. Are you running the test in C locale (because
> it looks a bit
Alvaro Herrera wrote:
Hi,
I'm seeing the following regression failure in PL/Tcl. It seems to be
just an ordering issue, and the order in which a trigger is fired.
This is a pristine, freshly updated copy of CVS head as of right now.
I'm not sure why the buildfarm is not having this problem.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm seeing the following regression failure in PL/Tcl. It seems to be
> just an ordering issue, and the order in which a trigger is fired.
Works on my x86_64 box. Are you running the test in C locale (because
it looks a bit like a sort-ordering issue)
Alvaro Herrera wrote:
> Hi,
>
> I'm seeing the following regression failure in PL/Tcl. It seems to be
> just an ordering issue, and the order in which a trigger is fired.
>
> This is a pristine, freshly updated copy of CVS head as of right now.
I removed the derived files (moral equivalent of m
Hi,
I'm seeing the following regression failure in PL/Tcl. It seems to be
just an ordering issue, and the order in which a trigger is fired.
This is a pristine, freshly updated copy of CVS head as of right now.
I'm not sure why the buildfarm is not having this problem.
alvherre=# select versi
Andrew Dunstan wrote:
>
>
> ohp@pyrenet.fr wrote:
>
> >In the meantime would'nt it be nice to try to understand what happens and
> >correct it?
> >
> >I'm a bit afraid that 8.1 is not used on unixware because people don't
> >have/want the patch installed.
> >
> >
> >
>
> All the evidence is t
On Jul 27 2005, Bruce Momjian wrote:
Andrew Dunstan wrote:
>
>
> ohp@pyrenet.fr wrote:
>
> > In the meantime would'nt it be nice to try to understand what happens
> > and correct it?
> >
> >I'm a bit afraid that 8.1 is not used on unixware because people don't
> >have/want the patch install
On Jul 27 2005, Andrew Dunstan wrote:
ohp@pyrenet.fr wrote:
>In the meantime would'nt it be nice to try to understand what happens and
>correct it?
>
>I'm a bit afraid that 8.1 is not used on unixware because people don't
>have/want the patch installed.
>
>
>
All the evidence is that this
ohp@pyrenet.fr wrote:
In the meantime would'nt it be nice to try to understand what happens and
correct it?
I'm a bit afraid that 8.1 is not used on unixware because people don't
have/want the patch installed.
All the evidence is that this is a compiler bug. The apparent workaround
for
ohp@pyrenet.fr wrote:
> In the meantime would'nt it be nice to try to understand what happens
> and correct it?
>
> I'm a bit afraid that 8.1 is not used on unixware because people
> don't have/want the patch installed.
>
> Regards
Let's see what they find, first. They may have a work-around (
0500
> From: Larry Rosenman
> To: ohp@pyrenet.fr
> Cc: Tom Lane <[EMAIL PROTECTED]>,
> 'pgsql-hackers list'
> Subject: Re: [HACKERS] regression failure on latest CVS
>
> On Jul 26 2005, ohp@pyrenet.fr wrote:
>
> > On Mon, 25 Jul 2005, Tom Lane wrote:
>
On Mon, 25 Jul 2005, Tom Lane wrote:
> Date: Mon, 25 Jul 2005 23:26:20 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Larry Rosenman
> Cc: ohp@pyrenet.fr, 'pgsql-hackers list'
> Subject: Re: [HACKERS] regression failure on latest CVS
>
> "Larry Rosenm
On Jul 26 2005, ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Tom Lane wrote:
> FWIW, I just checked that CVS tip works OK for me without these options,
> with either integer or float timestamps. I don't see any new warnings,
> either.
> It could well be that the recent changes have introduced so
Tom Lane wrote:
> "Larry Rosenman" writes:
>> For those following along at home:
>
>> Removing --enable-cassert and --enable-debug from the options causes
>> Firefly to fail.
>
> FWIW, I just checked that CVS tip works OK for me without these
> options, with either integer or float timestamps.
"Larry Rosenman" writes:
> For those following along at home:
> Removing --enable-cassert and --enable-debug from the options causes
> Firefly to fail.
FWIW, I just checked that CVS tip works OK for me without these options,
with either integer or float timestamps. I don't see any new warnings,
Larry Rosenman wrote:
> ohp@pyrenet.fr wrote:
>> On Mon, 25 Jul 2005, Larry Rosenman wrote:
>>
>>> Date: 25 Jul 2005 12:47:01 -0500
>>> From: Larry Rosenman
>>> To: ohp@pyrenet.fr
>>> Cc: pgsql-hackers list
>>> Subject: Re: [HACKERS] r
Larry Rosenman wrote:
ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman
To: ohp@pyrenet.fr
Cc: pgsql-hackers list
Subject: Re: [HACKERS] regression failure on latest CVS
On Jul 25 2005, ohp@pyrenet.fr wrote
man
>>>> To: ohp@pyrenet.fr
>>>> Cc: pgsql-hackers list
>>>> Subject: Re: [HACKERS] regression failure on latest CVS
>>>>
>>>> On Jul 25 2005, ohp@pyrenet.fr wrote:
>>>>
>>>>
>>>>
>>>>&g
ohp@pyrenet.fr wrote:
> On Mon, 25 Jul 2005, Larry Rosenman wrote:
>
>> Date: 25 Jul 2005 12:47:01 -0500
>> From: Larry Rosenman
>> To: ohp@pyrenet.fr
>> Cc: pgsql-hackers list
>> Subject: Re: [HACKERS] regression failure on latest CVS
>>
>>
./configure
>
> This is the problem I have.
>
> Regards
> On Mon, 25 Jul 2005, Larry Rosenman wrote:
>
> > Date: 25 Jul 2005 09:00:41 -0500
> > From: Larry Rosenman
> > To: ohp@pyrenet.fr
> > Cc: pgsql-hackers list
> > Subject: Re: [HACKERS] r
On Mon, 25 Jul 2005, Larry Rosenman wrote:
> Date: 25 Jul 2005 12:47:01 -0500
> From: Larry Rosenman
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] regression failure on latest CVS
>
> On Jul 25 2005, ohp@pyrenet.fr wrote:
>
> > Hi Larry,
On Jul 25 2005, ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
> Date: 25 Jul 2005 12:47:01 -0500
> From: Larry Rosenman
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] regression failure on latest CVS
>
> On Jul 25 2005,
On Jul 25 2005, ohp@pyrenet.fr wrote:
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configure
Do we have a clue as to which .c module the compiler/optimizer is (possibly)
screwing up?
I have connections in SCO's compiler group
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] regression failure on latest CVS
>
> On Jul 25 2005, ohp@pyrenet.fr wrote:
>
> > Sorry to follow up my own post but this is weird.
> >
> > I've tested again and more closely.
> > And intervall check is ok w
Bruce Momjian writes:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> FYI, I am seeing the same stats regression failures in CVS, even after
>>> the recent commits to improve sleep().
>>
>> Has anyone else seen this failure since updating to latest pgstat.c?
> My regression tests are fine now.
Tom Lane wrote:
> Bruce Momjian writes:
> > FYI, I am seeing the same stats regression failures in CVS, even after
> > the recent commits to improve sleep().
>
> As near as I can tell, this is fixed by pgstat.c rev 1.101. I'm not
> clear why --- the patch certainly zeroes some table fields that
On Jul 25 2005, ohp@pyrenet.fr wrote:
Sorry to follow up my own post but this is weird.
I've tested again and more closely.
And intervall check is ok when configured with --enable-debug and fails
(with the same error) otherwise.
It could be a compiler optimizer bug or the way the code is writt
Sorry to follow up my own post but this is weird.
I've tested again and more closely.
And intervall check is ok when configured with --enable-debug and fails
(with the same error) otherwise.
It could be a compiler optimizer bug or the way the code is written.
Could someone point me to the source
Bruce Momjian writes:
> FYI, I am seeing the same stats regression failures in CVS, even after
> the recent commits to improve sleep().
As near as I can tell, this is fixed by pgstat.c rev 1.101. I'm not
clear why --- the patch certainly zeroes some table fields that were
going uninitialized bef
FYI, I am seeing the same stats regression failures in CVS, even after
the recent commits to improve sleep().
--
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
+
> That might be explained by this 8.0.2/7.4.8 fix:
> This does bring up a question for Rod: have you installed a release
> including the above fix, and if so have you noticed the
> crash-after-SIGTERM problem since then?
We skipped 8.0.2 and went to 8.0.3 near the beginning of the month.
We we
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> I once noticed that there was something weird of Lock in win32 pg8.0.1. If
> you have many connections work concurrently intensively(say contrib/pgbench)
> and do fast shutdown in the middle, you will see an assertation failure
> here:
> if (lock->nRe
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> Hmph. No obvious reason why that would be platform-dependent. Is it
> completely repeatable for you? (You might try the advice I just gave
> Dave Cramer: make distclean and rebuild to ensure you've got fully
> consistent bits ...)
>
I once noticed that
Andrew Dunstan wrote:
It's not 100% repeatable, but I have seen it about 60% of the time
over 8 or 10 runs.
But now I can't reproduce it at all. :-(
cheers
andrew
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I just got this regression failure on Windows:
namespace.c::RelationIsVisible - line 319
Hmph. No obvious reason why that would be platform-dependent. Is it
completely repeatable for you? (You might try the
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>> I just got this regression failure on Windows:
> namespace.c::RelationIsVisible - line 319
Hmph. No obvious reason why that would be platform-dependent. Is it
completely repeatable for you? (You might try the advice I just gave
Dave Cramer: make d
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I just got this regression failure on Windows:
If it's repeatable, could you get a debugger stack trace from the
errfinish call? Or even just add "\set VERBOSITY verbose" to the
test script so we can tell which of the many
On Thu, Jun 23, 2005 at 11:08:55AM -0400, Andrew Dunstan wrote:
> I just got this regression failure on Windows:
Maybe it has to do with being unable to drop the relcache file?
> == pgsql.2220/src/test/regress/regression.diffs
> ===
> *** ./expected/prepared_xact
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I just got this regression failure on Windows:
If it's repeatable, could you get a debugger stack trace from the
errfinish call? Or even just add "\set VERBOSITY verbose" to the
test script so we can tell which of the many instances of that
string this
I just got this regression failure on Windows:
== pgsql.2220/src/test/regress/regression.diffs
===
*** ./expected/prepared_xacts.out Thu Jun 23 10:20:28 2005
--- ./results/prepared_xacts.outThu Jun 23 10:45:06 2005
***
*** 179,189
-- Commi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Machine details:
> Solaris / 2.8
> regression diffs:
> *** ./expected/cube.out Tue Sep 28 15:25:33 2004
> --- ./results/cube.outTue Sep 28 15:55:16 2004
> ***
> *** 142,148
> SELECT '-1e-700'::cube AS cube;
>cube
>
First error know to be caught by the buildfarm - this is one of DarcyB's
test client machines. All the details below were pulled from the
buildfarm test server's database.
This report is from HEAD, but it might also apply to earlier branches.
cheers
andrew
Machine details:
Sola
Dear Hans,
>
> Robert,
>
> Are you planning to use Intel's C compiler in production?
> We tried that some time ago and corrupted our database cluster almost
> instantly (for some reason we have not investigated any further).
> I highly recommend to do some stress testing to see if everything wor
Robert,
Are you planning to use Intel's C compiler in production?
We tried that some time ago and corrupted our database cluster almost
instantly (for some reason we have not investigated any further).
I highly recommend to do some stress testing to see if everything works
nicely.
I'd be pleased
Dear All,
I built PG 8.0 beta1 on an Itanium 2 platform using the Intel compilers
version 8, and got one real difference in the regression tests that affected
int2, int4, union, and numerology. Here's the key difference:
horta postgres 177 > diff -c int4.out ../expected/
*** int4.outTu
Thank you all once again for your hard work and dedication to quality
software! Looking forward to 8.0.
platform: Mac OS X 10.3.5
evironment and ./configure
PGVER="8.0.0"
PGPORT=54800
PGUSER=postgres
PGTAGNAME="pgsql 8.0.0"
PGSRCROOT=/usr/local/src/pgsql-8.0.0
PGINSTROOT=/usr/local/pgsql-8.0.0
P
I am seeing a hung regression test just after "numerology" on Unix.
If you set USE_PGTZ to yes in Makefile.global and define USE_PGTZ in
pg_config.h, you might see it too.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+
> email. The current patch is attached -- Tom hasn't yet gotten back to
> me on whether this fixes the problem for him on HPUX, but it fixes my
> OS X box.
Fixes issues under win32. Thanks.
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am seeing the following regression failure for current CVS. On my OS,
> BSD/OS 4.3, it seems once you hit Infinity, you can't negate it.
> /usr/include/math.h has:
> /* Generate an overflow to create +Inf; the multiply shuts up gcc 1 */
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am seeing the following regression failure for current CVS. On my
> OS, BSD/OS 4.3, it seems once you hit Infinity, you can't negate it.
Actually, I suspect the problem is that isinf() on your platform
returns 1 for any infinity (rather than -1 for ne
I am seeing the following regression failure for current CVS. On my OS,
BSD/OS 4.3, it seems once you hit Infinity, you can't negate it.
/usr/include/math.h has:
/* Generate an overflow to create +Inf; the multiply shuts up gcc 1 */
#define HUGE_VAL(1e250*1e250) /* IEEE
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Kurt Roeckx wrote:
>> On Sun, Oct 26, 2003 at 08:27:52PM +0900, Tatsuo Ishii wrote:
>>> I have seen following regression failure with current(I cvs up'ed 10
>>> minutes ago). Any thought? This is Linux kernel 2.4.22 with glibc
>>> 2.2.4.
>>
>> Maybe the
Kurt Roeckx wrote:
> On Sun, Oct 26, 2003 at 08:27:52PM +0900, Tatsuo Ishii wrote:
> > I have seen following regression failure with current(I cvs up'ed 10
> > minutes ago). Any thought? This is Linux kernel 2.4.22 with glibc
> > 2.2.4.
>
> Maybe the change of TZ (summer to winter time) tonight ca
On Sun, Oct 26, 2003 at 08:27:52PM +0900, Tatsuo Ishii wrote:
> I have seen following regression failure with current(I cvs up'ed 10
> minutes ago). Any thought? This is Linux kernel 2.4.22 with glibc
> 2.2.4.
Maybe the change of TZ (summer to winter time) tonight caused
this.
Kurt
---
I have seen following regression failure with current(I cvs up'ed 10
minutes ago). Any thought? This is Linux kernel 2.4.22 with glibc
2.2.4.
--
Tatsuo Ishii
*** ./expected/horology.out Mon Sep 29 17:53:48 2003
--- ./results/horology.out Sun Oct 26 20:21:59 2003
***
*** 583,59
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Jeroen T. Vermeulen wrote:
> On Sat, Feb
Neil Conway <[EMAIL PROTECTED]> writes:
> On Sat, 2003-03-08 at 21:29, Tom Lane wrote:
>> Do you use --enable-depend when configuring? I don't, so I know that
>> I take some risk of build errors when I do things wrong.
> Yeah, I did -- which I why when I reported it initially I assumed that a
> b
On Sat, 2003-03-08 at 21:29, Tom Lane wrote:
> Do you use --enable-depend when configuring? I don't, so I know that
> I take some risk of build errors when I do things wrong.
Yeah, I did -- which I why when I reported it initially I assumed that a
build problem wasn't the cause.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> writes:
> I suppose we can just regard it as a build problem, then? Not sure what
> the actual culprit was, though...
I'm mystified too. But unless we see it again, I think we have to write
it off as a build error.
Do you use --enable-depend when configuring? I d
On Sat, 2003-03-08 at 12:41, Tom Lane wrote:
> Can you still reproduce the problem after a clean rebuild?
No -- I ran "cvs update", "make clean", followed by 10 runs of the
regression tests but I didn't get any similar failures.
I suppose we can just regard it as a build problem, then? Not sure w
Tom Lane wrote:
I've spent the morning trying to reproduce this, without success. After
a "make maintainer-clean", cvs update, full rebuild cycle, I cannot get
anything funny to happen in "make check" under HPUX, RH Linux 8.0, or
OS X.
I'm a bit hesitant to write it off as a build problem, because
I said:
> Neil Conway <[EMAIL PROTECTED]> writes:
>> About 1 in every 5 runs of the (parallel) regression tests are failing
>> for me with CVS HEAD: the triggers, inherit, vacuum, sanity_check, and
>> misc tests fail. I can make the failures occur fairly consistently by
>> running "make check" over
> Yipes. I have not been running the parallel tests (my habit is to run
> make installcheck, instead) but there is clearly something busted.
> I got a bunch of failures similar to yours in my first attempt with
> make check on HPUX --- see attached.
>
> > Any ideas on what the cause might be?
>
Neil Conway <[EMAIL PROTECTED]> writes:
> About 1 in every 5 runs of the (parallel) regression tests are failing
> for me with CVS HEAD: the triggers, inherit, vacuum, sanity_check, and
> misc tests fail. I can make the failures occur fairly consistently by
> running "make check" over and over agai
On Fri, 2003-03-07 at 17:05, Doug McNaught wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
>
> > About 1 in every 5 runs of the (parallel) regression tests are failing
> > for me with CVS HEAD: the triggers, inherit, vacuum, sanity_check, and
> > misc tests fail. I can make the failures occur fai
Neil Conway <[EMAIL PROTECTED]> writes:
> About 1 in every 5 runs of the (parallel) regression tests are failing
> for me with CVS HEAD: the triggers, inherit, vacuum, sanity_check, and
> misc tests fail. I can make the failures occur fairly consistently by
> running "make check" over and over aga
About 1 in every 5 runs of the (parallel) regression tests are failing
for me with CVS HEAD: the triggers, inherit, vacuum, sanity_check, and
misc tests fail. I can make the failures occur fairly consistently by
running "make check" over and over again until the problem crops up.
The platform is L
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
>Joe Conway <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Hm, I just had regression tests pass earlier this evening on RHL 8.0
>>> (also HPUX 10.20). Are you using default config, or
>>> --enable-integer-datetimes?
>
>> I'm u
On Sat, Feb 22, 2003 at 03:09:13AM -0500, Tom Lane wrote:
>
> Mph. It fails for me too when I use --enable-integer-datetimes. Looks
> like that patch still needs some work...
Yeah. I'm really, really, *really* sorry for submitting it in the state
it was in. I shouldn't have done that just bef
Joe Conway <[EMAIL PROTECTED]> writes:
> I'm seeing a regression failure on the horology test on two different
> machines. I'd venture a guess that it is related to this change:
>http://archives.postgresql.org/pgsql-committers/2003-02/msg00166.php
It seems to be a problem with signed vs unsig
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, I just had regression tests pass earlier this evening on RHL 8.0
>> (also HPUX 10.20). Are you using default config, or
>> --enable-integer-datetimes?
> I'm using --enable-integer-datetimes on both.
Mph. It fails for me too when I
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Sorry -- one is Red Hat 8.0/Intel P3 and one is Red Hat 7.3/AMD Athlon.
Hm, I just had regression tests pass earlier this evening on RHL 8.0
(also HPUX 10.20). Are you using default config, or
--enable-integer-datetimes?
I'm using --enable-i
Joe Conway <[EMAIL PROTECTED]> writes:
> Sorry -- one is Red Hat 8.0/Intel P3 and one is Red Hat 7.3/AMD Athlon.
Hm, I just had regression tests pass earlier this evening on RHL 8.0
(also HPUX 10.20). Are you using default config, or
--enable-integer-datetimes?
regards,
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I'm seeing a regression failure on the horology test on two different
machines.
Uh ... what machines, and what failure exactly?
Sorry -- one is Red Hat 8.0/Intel P3 and one is Red Hat 7.3/AMD Athlon.
Regression diff attached.
Joe
*** ./expe
Joe Conway <[EMAIL PROTECTED]> writes:
> I'm seeing a regression failure on the horology test on two different
> machines.
Uh ... what machines, and what failure exactly?
regards, tom lane
---(end of broadcast)---
TIP 6: Ha
I'm seeing a regression failure on the horology test on two different
machines. I'd venture a guess that it is related to this change:
http://archives.postgresql.org/pgsql-committers/2003-02/msg00166.php
Joe
---(end of broadcast)---
TIP 5: Have
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> Would you poke into it and see why?
> I can, but I'm not sure what you want me to do -
It shouldn't be that hard to find why you're getting zeroes instead of
expected results. I'd look at those cases first.
regards
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Latest CVS, timetz and horology is failing...
Would you poke into it and see why?
I made some recent adjustments to the rounding code in timetz, but I
didn't expect any portability issues to surface...
regards, tom l
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > Latest CVS, timetz and horology is failing...
>
> Would you poke into it and see why?
I can, but I'm not sure what you want me to do - I'm not really familiar
with it all bar the stuff I attached to the email...
Chris
-
Latest CVS, timetz and horology is failing...
parallel group (13 tests): text name varchar float4 char int2 boolean oid
int8 float8 bit int4 numeric
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text
* Tom Lane <[EMAIL PROTECTED]> [001104 18:40]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Looks like someone changed an error message, but didn't upgrade the
> > expected file...
>
> Yup. I just undid the error message change, because the new text did
> not seem like an improvement...
I ag
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Looks like someone changed an error message, but didn't upgrade the
> expected file...
Yup. I just undid the error message change, because the new text did
not seem like an improvement...
regards, tom lane
Looks like someone changed an error message, but didn't upgrade the
expected file...
(Current sources/multibyte/UnixWare 7.1.1)
*** ./expected/geometry.out Tue Sep 12 16:07:16 2000
--- ./results/geometry.out Sat Nov 4 15:55:05 2000
***
*** 127,133
| (-5,-12)
> > Hmm. I wonder why cc and gcc are doing different math. Wierd.
>
> Not only that, but you get different results with the same compiler
> depending on different optimization settings. The joys of
> binary floating point...
Same on AIX.
Andreas
Larry Rosenman writes:
> Hmm. I wonder why cc and gcc are doing different math. Wierd.
Not only that, but you get different results with the same compiler
depending on different optimization settings. The joys of binary floating
point...
> I suspect it might have to do with what gcc was comp
* Peter Eisentraut <[EMAIL PROTECTED]> [001029 14:32]:
> Larry Rosenman writes:
>
> > Would the timezone change last night be causing this?
>
> The "timestamp" failure, yes. The "geometry", no. Geometry simply needs
> a new expected file, but unfortunately they're not the same for "cc" and
>
Would the timezone change last night be causing this?
Larry
* Larry Rosenman <[EMAIL PROTECTED]> [001029 12:55]:
> Same sources, configured as:
>
> CC=cc CXX=CC ./configure --prefix=/home/ler/pg-test --enable-syslog \
> --with-CXX --with-perl --with-includes=/usr/local/include \
>
Larry Rosenman writes:
> Would the timezone change last night be causing this?
The "timestamp" failure, yes. The "geometry", no. Geometry simply needs
a new expected file, but unfortunately they're not the same for "cc" and
"gcc"...
--
Peter Eisentraut [EMAIL PROTECTED] http://yi
Same sources, configured as:
CC=cc CXX=CC ./configure --prefix=/home/ler/pg-test --enable-syslog \
--with-CXX --with-perl --with-includes=/usr/local/include \
--with-libs=/usr/local/lib
only fails the following:
*** ./expected/timestamp.outFri Sep 22 10:33:31 2000
--- ./res
Configured as:
CC=cc CXX=CC ./configure --prefix=/home/ler/pg-test --enable-syslog --with-CXX
--with-perl --enable-multibyte --with-includes=/usr/local/include
--with-libs=/usr/local/lib
Todays sources fail regression. Here is the regression.diffs:
*** ./expected/int8.out Fri Apr 7 14:17:39
98 matches
Mail list logo
