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) |
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
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.com
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 only
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 moment is
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
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
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 that
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 still in use
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 seeing. Did
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:
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 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 running
a
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
above,
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 relcache
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
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 but
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
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
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
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 that
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
---
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
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
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:26
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
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 path
to
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
[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). Let me
29 matches
Mail list logo
