"make check" produces the following regression.diffs:
*** ./expected/geometry.out Fri Oct 31 22:07:07 2003
--- ./results/geometry.out Thu Aug 26 00:51:46 2004
***
*** 117,123
| (5.1,34.5) | [(1,2),(3,4)] | (3,4)
| (-5,-12) | [(1,2),(3,
As I posted yesterday, I've got the priviledges test failing (it's the
only one). I posted a single-step run, and I've not heard from
anyone.
I can set up an account for anyone that want's to play with it to figure
out what I've got messed up
LER
just to refresh folks memory, here is the failu
Strange. I know we check for bison >= 1.875, and you have that, and so
do I, but I don't see those regression failures. Is it possible you
have old bison output files from an older bison release?
---
Neil Conway wrote:
> W
I didn't know about "make maintainer-clean" either.
---
Neil Conway wrote:
> On Thu, Aug 07, 2003 at 04:09:33PM -0400, Tom Lane wrote:
> I think the check is only a warning though; and the only thing that
> > actually fails
On Thu, Aug 07, 2003 at 04:09:33PM -0400, Tom Lane wrote:
I think the check is only a warning though; and the only thing that
> actually fails to build is ecpg's preproc.y. It's possible his current
> copy of parser/gram.c was built with an older bison before he hit the
> hard failure, and then h
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Strange. I know we check for bison >= 1.875, and you have that, and so
> do I, but I don't see those regression failures. Is it possible you
> have old bison output files from an older bison release?
I think the check is only a warning though; and the
When I run the regression tests against current sources, I get
failures because bison-generated error messages use "parse
error", not "syntax error". I vaguely recall running into
this issue before I left for the summer -- did we resolve
it?
[EMAIL PROTECTED] neil]$ uname -a
FreeBSD arch.wavefire.
OK, on it now!
---
Tom Lane wrote:
> I said:
> >> I have a theory about the failures that occur while creating tables.
> >> If a relcache flush were to occur due to SI buffer overrun between
> >> creation of the new rel's re
I said:
>> I have a theory about the failures that occur while creating tables.
>> If a relcache flush were to occur due to SI buffer overrun between
>> creation of the new rel's relcache entry by RelationBuildLocalRelation
>> and completion of the command, then you'd see an error exactly like the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, is the attached regression diff considered normal? This was
> > generated by current CVS.
>
> Well, this *looks* like it could be an example of the SI-overrun-
> during-create behavior I was talking about. But if you weren't ru
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, is the attached regression diff considered normal? This was
> generated by current CVS.
Well, this *looks* like it could be an example of the SI-overrun-
during-create behavior I was talking about. But if you weren't running
a verbose log to show
Tom, is the attached regression diff considered normal? This was
generated by current CVS.
I am trying to determine what is a normal error and what is something to
be concerned about.
Also, I am up to Feb 25 with no errors, but am still testing.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am now seeing this error in 2003-03-03.
> CREATE TABLE INSERT_CHILD (cx INT default 42,
> cy INT CHECK (cy > x))
> INHERITS (INSERT_TBL);
> + ERROR: RelationClearRelation: relation 130996 deleted while still in use
Define "now seein
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am now seeing this error in 2003-03-03.
>
> > CREATE TABLE INSERT_CHILD (cx INT default 42,
> > cy INT CHECK (cy > x))
> > INHERITS (INSERT_TBL);
> > + ERROR: RelationClearRelation: relation 130996 deleted while s
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am now seeing this error in 2003-03-03.
> CREATE TABLE INSERT_CHILD (cx INT default 42,
> cy INT CHECK (cy > x))
> INHERITS (INSERT_TBL);
> + ERROR: RelationClearRelation: relation 130996 deleted while still in use
I have a theory about the failures
I am now seeing this error in 2003-03-03.
CREATE TABLE INSERT_CHILD (cx INT default 42,
cy INT CHECK (cy > x))
INHERITS (INSERT_TBL);
+ ERROR: RelationClearRelation: relation 130996 deleted while still in use
-
I am testing this today. I found 2003-03-03 to not generate a failure
in 20 tests, so I am moving forward to April/May.
---
Robert Creager wrote:
-- Start of PGP signed section.
>
> I will stand by the fact that I cannot g
I will stand by the fact that I cannot generate failures from
2003-02-15 (200+ runs), and I can from 2003-02-16. Just to make sure I
didn't screw up the cvs usage, I'll try again tonight if I get the
chance and re-download re-test these two days.
I can set up a script that will step through week
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have only been running nightly paralell regression runs since June 27,
> so it is possible that the paralell regression was broken in February,
> fixed in May, then broken some time after that.
Any further progress on this?
My best theory at the momen
On Sat, 26 Jul 2003 21:08:46 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> said something like:
>
> I am seeing repeatable success from a CVS of 2003-05-01, and
> repeatable failure from current CVS.
>
> I have only been running nightly paralell regression runs since June
> 27, so it is possible
On Sat, 26 Jul 2003 20:24:56 -0400
Tom Lane <[EMAIL PROTECTED]> said something like:
>
> What time of day did your successive pulls correspond to, anyway?
> (I believe my cvs2cl printout above is showing me EST.)
>
> regards, tom lane
>
>
I'm MST, and I did not specify a
I am seeing repeatable success from a CVS of 2003-05-01, and repeatable
failure from current CVS.
I have only been running nightly paralell regression runs since June 27,
so it is possible that the paralell regression was broken in February,
fixed in May, then broken some time after that.
I will
Tom Lane wrote:
> Robert Creager <[EMAIL PROTECTED]> writes:
> > 2003-02-15 passes 50/50 and 33/33 on second pass (so far)
> > 2003-02-16 fails 6/50
>
> I looked in the CVS logs while waiting for a compile, and the only patch
> I see that goes anywhere near the locking or cache code around that ti
Robert Creager <[EMAIL PROTECTED]> writes:
> 2003-02-15 passes 50/50 and 33/33 on second pass (so far)
> 2003-02-16 fails 6/50
I looked in the CVS logs while waiting for a compile, and the only patch
I see that goes anywhere near the locking or cache code around that time
is this one:
2003-02-17
Robert Creager <[EMAIL PROTECTED]> writes:
> Looks like something was done after the 15'th...
> 2003-02-15 passes 50/50 and 33/33 on second pass (so far)
> 2003-02-16 fails 6/50
As far back as that! Okay, many thanks for the info --- that will help.
I'm buried in error message editing right now
I found it (I think)...
Looks like something was done after the 15'th...
2003-02-15 passes 50/50 and 33/33 on second pass (so far)
2003-02-16 fails 6/50
vacuum failed 1 times
misc failed 3 times
sanity_check failed 3 times
inherit failed 1 times
triggers failed 4 times
2003-02-18
Applied. Sorry I missed this one. I did a clean compile and initdb for
testing, but forgot regression.
---
Neil Conway wrote:
> Seems like a result of Alverro's cluster patch -- looks like the patch
> didn't updated the ex
Seems like a result of Alverro's cluster patch -- looks like the patch
didn't updated the expected results for the regression tests
fully. Diffs below.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
*** ./expected/cluster.out Fri Nov 15 12:35:36 2002
--- ./results
On Fri, Sep 20, 2002 at 01:12:17PM -0400, Bruce Momjian wrote:
>
> Tom has fixed it. Sorry I didn't test earlier.
Thanks.
> Neil Conway wrote:
> > It seems the 'numeric' and 'int8' tests are failing in CVS HEAD. The
> > culprit seems to be the recent to_char() change made by Karel, but I
> >
Tom has fixed it. Sorry I didn't test earlier.
---
Neil Conway wrote:
> It seems the 'numeric' and 'int8' tests are failing in CVS HEAD. The
> culprit seems to be the recent to_char() change made by Karel, but I
> haven't
It seems the 'numeric' and 'int8' tests are failing in CVS HEAD. The
culprit seems to be the recent to_char() change made by Karel, but I
haven't verified that. The diff follows.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
*** ./expected/int8.out Fri Jan 26 17:50:2
On Tuesday 13 August 2002 03:52 pm, Peter Eisentraut wrote:
> Tatsuo Ishii writes:
> > The $libdir variable is defined at the compile time and it points to
> > $prefix/lib. Apparently it points to different place while doing
> > regression tests. One idea is replacing $lindir with the absolute pat
Tatsuo Ishii writes:
> The $libdir variable is defined at the compile time and it points to
> $prefix/lib. Apparently it points to different place while doing
> regression tests. One idea is replacing $lindir with the absolute path
> to $prefix/lib. However I wonder this would break some installa
[Cced to hackers list]
> I'm seeing a regression test failure with the latest CVS code, in the
> 'conversion' test. I've attached the 'regression.diff' file -- the
> failure occurs consistently on my machine.
>
> I'm mailing you because I believe the test in question is for code you
> wrote). Le
34 matches
Mail list logo