[HACKERS] regression test failure with HEAD on OSX
"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,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (-0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) --- 117,123 | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) == The platform is OSX 10.3.5. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Regression Test Failure/UnixWare
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 failure: *** ./expected/privileges.out Thu Oct 9 20:49:31 2003 --- ./results/privileges.outSat Oct 25 12:04:45 2003 *** *** 247,253 (1 row) CREATE FUNCTION testfunc3(int) RETURNS int AS 'select 2 * $1;' LANGUAGE sql; -- fail - ERROR: permission denied for language sql SET SESSION AUTHORIZATION regressuser3; SELECT testfunc1(5); -- fail ERROR: permission denied for function testfunc1 --- 247,252 == -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] regression test failure
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: > 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 5.1-CURRENT FreeBSD 5.1-CURRENT #9: Fri Jul 25 12:10:58 > PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WORKSTATION-5.0-SMP i386 > [EMAIL PROTECTED] neil]$ bison --version > bison (GNU Bison) 1.875 > [EMAIL PROTECTED] neil]$ flex --version > flex version 2.5.4 > > regression.diffs is attached. > > -Neil > > P.S. Someone should go ahead and re-generate INSTALL from > the latest SGML: INSTALL still claims that we need bison > 1.50 or greater. > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] regression test failure
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 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 he didn't go back and rebuild after updating > > bison. > > Uh, yeah -- of course, that's exactly what the problem was. I had > assumed, wrongly of course, that "make distclean" removed bison > output. > > I feel stupid :-) > > -Neil > > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] regression test failure
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 he didn't go back and rebuild after updating > bison. Uh, yeah -- of course, that's exactly what the problem was. I had assumed, wrongly of course, that "make distclean" removed bison output. I feel stupid :-) -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] regression test failure
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 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 he didn't go back and rebuild after updating bison. I'd suggest a "make maintainer-clean" and try again. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] regression test failure
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 5.1-CURRENT FreeBSD 5.1-CURRENT #9: Fri Jul 25 12:10:58 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WORKSTATION-5.0-SMP i386 [EMAIL PROTECTED] neil]$ bison --version bison (GNU Bison) 1.875 [EMAIL PROTECTED] neil]$ flex --version flex version 2.5.4 regression.diffs is attached. -Neil P.S. Someone should go ahead and re-generate INSTALL from the latest SGML: INSTALL still claims that we need bison 1.50 or greater. *** ./expected/strings.out Sat Jul 26 21:53:11 2003 --- ./results/strings.out Thu Aug 7 10:58:29 2003 *** *** 18,24 ' - next line' /* this comment is not allowed here */ ' - third line' AS "Illegal comment within continuation"; ! ERROR: syntax error at or near "' - third line'" at character 75 -- -- test conversions between various string types -- E021-10 implicit casting among the character data types --- 18,24 ' - next line' /* this comment is not allowed here */ ' - third line' AS "Illegal comment within continuation"; ! ERROR: parse error at or near "' - third line'" at character 75 -- -- test conversions between various string types -- E021-10 implicit casting among the character data types == *** ./expected/create_function_1.outThu Aug 7 10:39:56 2003 --- ./results/create_function_1.out Thu Aug 7 10:58:38 2003 *** *** 54,60 DETAIL: Actual return type is "unknown". CREATE FUNCTION test1 (int) RETURNS int LANGUAGE sql AS 'not even SQL'; ! ERROR: syntax error at or near "not" at character 1 CREATE FUNCTION test1 (int) RETURNS int LANGUAGE sql AS 'SELECT 1, 2, 3;'; ERROR: return type mismatch in function declared to return integer --- 54,60 DETAIL: Actual return type is "unknown". CREATE FUNCTION test1 (int) RETURNS int LANGUAGE sql AS 'not even SQL'; ! ERROR: parse error at or near "not" at character 1 CREATE FUNCTION test1 (int) RETURNS int LANGUAGE sql AS 'SELECT 1, 2, 3;'; ERROR: return type mismatch in function declared to return integer == *** ./expected/constraints.out Thu Aug 7 10:39:56 2003 --- ./results/constraints.out Thu Aug 7 10:58:50 2003 *** *** 45,56 -- syntax errors -- test for extraneous comma CREATE TABLE error_tbl (i int DEFAULT (100, )); ! ERROR: syntax error at or near "," at character 43 -- this will fail because gram.y uses b_expr not a_expr for defaults, -- to avoid a shift/reduce conflict that arises from NOT NULL being -- part of the column definition syntax: CREATE TABLE error_tbl (b1 bool DEFAULT 1 IN (1, 2)); ! ERROR: syntax error at or near "IN" at character 43 -- this should work, however: CREATE TABLE error_tbl (b1 bool DEFAULT (1 IN (1, 2))); DROP TABLE error_tbl; --- 45,56 -- syntax errors -- test for extraneous comma CREATE TABLE error_tbl (i int DEFAULT (100, )); ! ERROR: parse error at or near "," at character 43 -- this will fail because gram.y uses b_expr not a_expr for defaults, -- to avoid a shift/reduce conflict that arises from NOT NULL being -- part of the column definition syntax: CREATE TABLE error_tbl (b1 bool DEFAULT 1 IN (1, 2)); ! ERROR: parse error at or near "IN" at character 43 -- this should work, however: CREATE TABLE error_tbl (b1 bool DEFAULT (1 IN (1, 2))); DROP TABLE error_tbl; == *** ./expected/errors.out Mon Jul 21 13:29:40 2003 --- ./results/errors.outThu Aug 7 10:59:14 2003 *** *** 22,34 -- missing relation name select; ! ERROR: syntax error at or near ";" at character 7 -- no such relation select * from nonesuch; ERROR: relation "nonesuch" does not exist -- missing target list select from pg_database; ! ERROR: syntax error at or near "from" at character 8 -- bad name in target list select nonesuch from pg_database; ERROR: attribute "nonesuch" not found --- 22,34 -- missing relation name select; ! ERROR: parse error at or near ";" at character 7 -- no such relation select * from nonesuch; ERROR: relation "nonesuch" does not exist -- missing target list select from pg_database; ! ERROR: parse error at or near "from" at character 8 -- bad name in target list select nonesuch from pg_database; ERROR: attribute "nonesuch" not found *** *** 40,46 ERROR: attribute "nonesuch" not found -- bad select distinct on syntax, distinct attribute missing select distinct on (foobar) from
Re: [HACKERS] Regression test failure date.
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 entry by RelationBuildLocalRelation > >> and completion of the command, then you'd see an error exactly like the > >> above, because the relcache would try to rebuild the cache entry by > >> reading the pg_class and pg_attribute rows for the relation. > > After further study, though, the above theory falls flat on its face: > the relcache does *not* attempt to rebuild new relcache entries after > an SI overrun (see the comments to RelationCacheInvalidate). So I'm > back to wondering what the heck is causing any of these messages. > > I think we really need to see a stack trace from one of the failures. > Could you try running CVS tip with an "abort()" call replacing the > "relation %u deleted while still in use" elog? (It's line 1797 > in src/backend/utils/cache/relcache.c in CVS tip.) Then when you > get the failure, get a stack trace with gdb from the core dump. > > regards, tom lane > > ---(end of broadcast)--- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Regression test failure date.
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, because the relcache would try to rebuild the cache entry by >> reading the pg_class and pg_attribute rows for the relation. After further study, though, the above theory falls flat on its face: the relcache does *not* attempt to rebuild new relcache entries after an SI overrun (see the comments to RelationCacheInvalidate). So I'm back to wondering what the heck is causing any of these messages. I think we really need to see a stack trace from one of the failures. Could you try running CVS tip with an "abort()" call replacing the "relation %u deleted while still in use" elog? (It's line 1797 in src/backend/utils/cache/relcache.c in CVS tip.) Then when you get the failure, get a stack trace with gdb from the core dump. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Regression test failure date.
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 verbose log to show whether a cache flush occurred just before the > error, there's no way to know for sure. OK. > Right at the moment I am more interested in the other cases though > (cache lookup failure during DROP) since I have no plausible > explanation for them. Thanks. That's what I need to know. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Regression test failure date.
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 whether a cache flush occurred just before the error, there's no way to know for sure. Right at the moment I am more interested in the other cases though (cache lookup failure during DROP) since I have no plausible explanation for them. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Regression test failure date.
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.
---
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
>
> 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, because the relcache would try to rebuild the cache entry by
> reading the pg_class and pg_attribute rows for the relation. Which
> would possibly not exist yet, and even if they did exist they'd be
> invisible under SnapshotNow rules.
>
> However this bug is of long standing, and it doesn't seem all that
> probable as an explanation for your difficulties. It would be worth
> running the tests with log_min_messages set to DEBUG4 (along with the
> verbosity setting, please) and see if you observe "cache state reset"
> log entries just before the failures.
>
> In any case this would not explain failures during DROP TABLE, so
> there's another issue to look for.
>
> regards, tom lane
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
*** ./expected/constraints.out Mon Jul 28 13:50:13 2003
--- ./results/constraints.out Mon Jul 28 18:32:55 2003
***
*** 80,102
CREATE TABLE CHECK2_TBL (x int, y text, z int,
CONSTRAINT SEQUENCE_CON
CHECK (x > 3 and y <> 'check failed' and z < 8));
INSERT INTO CHECK2_TBL VALUES (4, 'check ok', -2);
INSERT INTO CHECK2_TBL VALUES (1, 'x check failed', -2);
! ERROR: new row for relation "check2_tbl" violates CHECK constraint "sequence_con"
INSERT INTO CHECK2_TBL VALUES (5, 'z check failed', 10);
! ERROR: new row for relation "check2_tbl" violates CHECK constraint "sequence_con"
INSERT INTO CHECK2_TBL VALUES (0, 'check failed', -2);
! ERROR: new row for relation "check2_tbl" violates CHECK constraint "sequence_con"
INSERT INTO CHECK2_TBL VALUES (6, 'check failed', 11);
! ERROR: new row for relation "check2_tbl" violates CHECK constraint "sequence_con"
INSERT INTO CHECK2_TBL VALUES (7, 'check ok', 7);
SELECT '' AS two, * from CHECK2_TBL;
! two | x |y | z
! -+---+--+
! | 4 | check ok | -2
! | 7 | check ok | 7
! (2 rows)
!
--
-- Check constraints on INSERT
--
--- 80,100
CREATE TABLE CHECK2_TBL (x int, y text, z int,
CONSTRAINT SEQUENCE_CON
CHECK (x > 3 and y <> 'check failed' and z < 8));
+ ERROR: relation 126581 deleted while still in use
INSERT INTO CHECK2_TBL VALUES (4, 'check ok', -2);
+ ERROR: relation "check2_tbl" does not exist
INSERT INTO CHECK2_TBL VALUES (1, 'x check failed', -2);
! ERROR: relation "check2_tbl" does not exist
INSERT INTO CHECK2_TBL VALUES (5, 'z check failed', 10);
! ERROR: relation "check2_tbl" does not exist
INSERT INTO CHECK2_TBL VALUES (0, 'check failed', -2);
! ERROR: relation "check2_tbl" does not exist
INSERT INTO CHECK2_TBL VALUES (6, 'check failed', 11);
! ERROR: relation "check2_tbl" does not exist
INSERT INTO CHECK2_TBL VALUES (7, 'check ok', 7);
+ ERROR: relation "check2_tbl" does not exist
SELECT '' AS two, * from CHECK2_TBL;
! ERROR: relation "check2_tbl" does not exist
--
-- Check constraints on INSERT
--
==
*** ./expected/misc.out Mon Jul 28 13:50:13 2003
--- ./results/misc.out Mon Jul 28 18:33:04 2003
***
*** 580,586
c
c_star
char_tbl
- check2_tbl
check_seq
check_tbl
circle_tbl
--- 580,585
***
*** 660,666
toyemp
varchar_tbl
xacttest
! (96 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer'))) AS
equip_name;
SELECT hobbies_by_name('basketball');
--- 659,665
toyemp
varchar_tbl
xacttest
! (95 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer'))) AS
equip_name;
SELECT hobbies_by_name('basketball');
==
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Regression test failure date.
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 you change something? Did you just run more test cycles and it happened one time? Did it suddenly start to happen a lot? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Regression test failure date.
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 > > Define "now seeing". Did you change something? Did you just run more > test cycles and it happened one time? Did it suddenly start to happen a > lot? Ran more cycles, that's all. I had reported 2003-03-03 was fine, but only ran a few tests that previous time. I am looking at the mid-February date range now. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Regression test failure date.
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 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, because the relcache would try to rebuild the cache entry by reading the pg_class and pg_attribute rows for the relation. Which would possibly not exist yet, and even if they did exist they'd be invisible under SnapshotNow rules. However this bug is of long standing, and it doesn't seem all that probable as an explanation for your difficulties. It would be worth running the tests with log_min_messages set to DEBUG4 (along with the verbosity setting, please) and see if you observe "cache state reset" log entries just before the failures. In any case this would not explain failures during DROP TABLE, so there's another issue to look for. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Regression test failure date.
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 wrote: > > 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 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 weekly dates starting from > > 'now' and see if the 02-16 problem might of been fixed and then > > re-introduced if you like. > > > > 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 > > > > Cheers, > > Rob > > > > On Mon, 28 Jul 2003 02:14:32 -0400 > > Tom Lane <[EMAIL PROTECTED]> said something like: > > > > > 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 that we have a problem with relcache > > > entry creation failing if it's interrupted by an SI inval message at > > > just the right time. I don't much want to grovel through six months > > > worth of changelog entries looking for candidate mistakes, though. > > > > > > regards, tom lane > > > > > > ---(end of > > > broadcast)--- TIP 3: if posting/reading > > > through Usenet, please send an appropriate > > > subscribe-nomail command to [EMAIL PROTECTED] so that > > > your message can get through to the mailing list cleanly > > > > > > > > > > > > -- > > 06:57:40 up 10 days, 10:57, 2 users, load average: 2.17, 2.08, 1.83 > -- End of PGP section, PGP failed! > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Regression test failure date.
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 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 weekly dates starting from > 'now' and see if the 02-16 problem might of been fixed and then > re-introduced if you like. > > 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 > > Cheers, > Rob > > On Mon, 28 Jul 2003 02:14:32 -0400 > Tom Lane <[EMAIL PROTECTED]> said something like: > > > 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 that we have a problem with relcache > > entry creation failing if it's interrupted by an SI inval message at > > just the right time. I don't much want to grovel through six months > > worth of changelog entries looking for candidate mistakes, though. > > > > regards, tom lane > > > > ---(end of > > broadcast)--- TIP 3: if posting/reading > > through Usenet, please send an appropriate > > subscribe-nomail command to [EMAIL PROTECTED] so that > > your message can get through to the mailing list cleanly > > > > > > > -- > 06:57:40 up 10 days, 10:57, 2 users, load average: 2.17, 2.08, 1.83 -- End of PGP section, PGP failed! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Regression test failure date.
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 weekly dates starting from 'now' and see if the 02-16 problem might of been fixed and then re-introduced if you like. 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 Cheers, Rob On Mon, 28 Jul 2003 02:14:32 -0400 Tom Lane <[EMAIL PROTECTED]> said something like: > 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 that we have a problem with relcache > entry creation failing if it's interrupted by an SI inval message at > just the right time. I don't much want to grovel through six months > worth of changelog entries looking for candidate mistakes, though. > > regards, tom lane > > ---(end of > broadcast)--- TIP 3: if posting/reading > through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that > your message can get through to the mailing list cleanly > > -- 06:57:40 up 10 days, 10:57, 2 users, load average: 2.17, 2.08, 1.83 pgp0.pgp Description: PGP signature
Re: [HACKERS] Regression test failure date.
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 that we have a problem with relcache entry creation failing if it's interrupted by an SI inval message at just the right time. I don't much want to grovel through six months worth of changelog entries looking for candidate mistakes, though. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Regression test failure date.
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 the paralell regression was broken in
> February, fixed in May, then broken some time after that.
>
> I will test June 1 now.
>
I don't know about that Bruce. When I grabbed 2003-05-01, I have 2
failures in 15 runs so far. One item I did have to change was to move
from bison 1.5 to bison 1.875.
I've attached included the first failure one.
*** ./expected/triggers.out Sat Nov 23 11:13:22 2002
--- ./results/triggers.out Sat Jul 26 20:10:18 2003
***
*** 87,92
--- 87,93
NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys are deleted
NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys2 are deleted
DROP TABLE pkeys;
+ ERROR: cache lookup of relation 129432 failed
DROP TABLE fkeys;
DROP TABLE fkeys2;
-- -- I've disabled the funny_dup17 test because the new semantics
==
*** ./expected/sanity_check.out Mon Aug 19 13:33:36 2002
--- ./results/sanity_check.out Sat Jul 26 20:10:20 2003
***
*** 58,68
pg_statistic| t
pg_trigger | t
pg_type | t
road| t
shighway| t
tenk1 | t
tenk2 | t
! (52 rows)
--
-- another sanity check: every system catalog that has OIDs should
have--- 58,69
pg_statistic| t
pg_trigger | t
pg_type | t
+ pkeys | t
road| t
shighway| t
tenk1 | t
tenk2 | t
! (53 rows)
--
-- another sanity check: every system catalog that has OIDs should
have
==
*** ./expected/misc.out Sat Jul 26 20:03:48 2003
--- ./results/misc.out Sat Jul 26 20:10:22 2003
***
*** 633,638
--- 633,639
onek2
path_tbl
person
+ pkeys
point_tbl
polygon_tbl
ramp
***
*** 657,663
toyemp
varchar_tbl
xacttest
! (93 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text
'mer'))) AS equip_name; SELECT hobbies_by_name('basketball');
--- 658,664
toyemp
varchar_tbl
xacttest
! (94 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text
'mer'))) AS equip_name; SELECT hobbies_by_name('basketball');
==
--
20:11:31 up 9 days, 12 min, 2 users, load average: 2.86, 2.30, 1.52
pgp0.pgp
Description: PGP signature
Re: [HACKERS] Regression test failure date.
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 timezone on the cvs updates. just I can re-do with a specific time/date if you tell me what you want. Or give me a range. I take a few minutes to do a complete cvs download. Later, Rob -- 19:10:13 up 8 days, 23:10, 2 users, load average: 0.00, 0.00, 0.00 pgp0.pgp Description: PGP signature
Re: [HACKERS] Regression test failure date.
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 test June 1 now. --- Robert Creager wrote: -- Start of PGP signed section. > > 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 fails 11/50 >constraints failed 5 times >sanity_check failed 3 times >misc failed 8 times >inherit failed 2 times >rules failed 1 times >triggers failed 5 times > > Cheers, > Rob > > -- > 17:42:41 up 8 days, 21:43, 2 users, load average: 3.62, 2.69, 2.35 -- End of PGP section, PGP failed! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Regression test failure date.
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 time > is this one: > > 2003-02-17 21:13 momjian > > * src/: backend/storage/lmgr/deadlock.c, > backend/storage/lmgr/lock.c, backend/storage/lmgr/proc.c, > backend/utils/adt/lockfuncs.c, include/storage/lock.h, > include/storage/proc.h: Rename 'holder' references to 'proclock' > for PROCLOCK references, for consistency. > > which seems like a safe change (I assume it was just a > search-and-replace; do you recall, Bruce?) and anyway the time is not > quite right. Yes, just a rename operation. > What time of day did your successive pulls correspond to, anyway? > (I believe my cvs2cl printout above is showing me EST.) For the date range: pgcvs log -d'2003-02-15 00:00:00 GMT<2003-02-18 00:00:00 GMT' -rHEAD I see: --- /src/include/optimizer/pathnode.h tgl Teach planner how to propagate pathkeys from sub-SELECTs in FROM up to the outer query. (The implementation is a bit klugy, but it would take nontrivial restructuring to make it nicer, which this is probably not worth.) This avoids unnecessary sort steps in examples like SELECT foo,count(*) FROM (SELECT ... ORDER BY foo,bar) sub GROUP BY foo which means there is now a reasonable technique for controlling the order of inputs to custom aggregates, even in the grouping case. --- /src/test/regress/expected/case.out tgl COALESCE() and NULLIF() are now first-class expressions, not macros that turn into CASE expressions. They evaluate their arguments at most once. Patch by Kris Jurka, review and (very light) editorializing by me. --- /doc/TODO.detail/exists momjian Remove IN/EXISTS TODO.detail item. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Regression test failure date.
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 21:13 momjian * src/: backend/storage/lmgr/deadlock.c, backend/storage/lmgr/lock.c, backend/storage/lmgr/proc.c, backend/utils/adt/lockfuncs.c, include/storage/lock.h, include/storage/proc.h: Rename 'holder' references to 'proclock' for PROCLOCK references, for consistency. which seems like a safe change (I assume it was just a search-and-replace; do you recall, Bruce?) and anyway the time is not quite right. What time of day did your successive pulls correspond to, anyway? (I believe my cvs2cl printout above is showing me EST.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Regression test failure date.
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 will look at the diffs in that timeframe tomorrow, unless someone beats me to it. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Regression test failure date.
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 fails 11/50 constraints failed 5 times sanity_check failed 3 times misc failed 8 times inherit failed 2 times rules failed 1 times triggers failed 5 times Cheers, Rob -- 17:42:41 up 8 days, 21:43, 2 users, load average: 3.62, 2.69, 2.35 pgp0.pgp Description: PGP signature
Re: [HACKERS] regression test failure (CVS HEAD)
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 expected results for the regression tests > fully. Diffs below. > > Cheers, > > Neil > > -- > Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC > > *** ./expected/cluster.outFri Nov 15 12:35:36 2002 > --- ./results/cluster.out Fri Nov 15 12:39:33 2002 > *** > *** 302,307 > --- 302,310 > INSERT INTO clstr_2 VALUES (1); > INSERT INTO clstr_3 VALUES (2); > INSERT INTO clstr_3 VALUES (1); > + -- "CLUSTER " on a table that hasn't been clustered > + CLUSTER clstr_2; > + ERROR: CLUSTER: No previously clustered index found on table clstr_2 > CLUSTER clstr_1_pkey ON clstr_1; > CLUSTER clstr_2_pkey ON clstr_2; > SELECT * FROM clstr_1 UNION ALL > *** > *** 344,349 > --- 347,364 >1 > (6 rows) > > + -- cluster a single table using the indisclustered bit previously set > + DELETE FROM clstr_1; > + INSERT INTO clstr_1 VALUES (2); > + INSERT INTO clstr_1 VALUES (1); > + CLUSTER clstr_1; > + SELECT * FROM clstr_1; > + a > + --- > + 1 > + 2 > + (2 rows) > + > -- clean up > \c - > DROP TABLE clstr_1; > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] regression test failure (CVS HEAD)
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/cluster.out Fri Nov 15 12:39:33 2002 *** *** 302,307 --- 302,310 INSERT INTO clstr_2 VALUES (1); INSERT INTO clstr_3 VALUES (2); INSERT INTO clstr_3 VALUES (1); + -- "CLUSTER " on a table that hasn't been clustered + CLUSTER clstr_2; + ERROR: CLUSTER: No previously clustered index found on table clstr_2 CLUSTER clstr_1_pkey ON clstr_1; CLUSTER clstr_2_pkey ON clstr_2; SELECT * FROM clstr_1 UNION ALL *** *** 344,349 --- 347,364 1 (6 rows) + -- cluster a single table using the indisclustered bit previously set + DELETE FROM clstr_1; + INSERT INTO clstr_1 VALUES (2); + INSERT INTO clstr_1 VALUES (1); + CLUSTER clstr_1; + SELECT * FROM clstr_1; + a + --- + 1 + 2 + (2 rows) + -- clean up \c - DROP TABLE clstr_1; ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] regression test failure in CVS HEAD
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 verified that. The diff follows. You're right. Sorry. > > SELECT '' AS to_char_14, to_char(q2, 'FM.999') FROM INT8_TBL; > >to_char_14 | to_char > > ! + > > ! | 456. > > ! | 4567890123456789. > > ! | 123. > > ! | 4567890123456789. > > ! | -4567890123456789. The results like this are right. Karel -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] regression test failure in CVS HEAD
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 verified that. The diff follows. > > Cheers, > > Neil > > -- > Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC > > *** ./expected/int8.out Fri Jan 26 17:50:26 2001 > --- ./results/int8.outFri Sep 20 12:37:25 2002 > *** > *** 245,256 > > SELECT '' AS to_char_14, to_char(q2, 'FM.999') FROM INT8_TBL; >to_char_14 | to_char > ! +--- > ! | 456 > ! | 4567890123456789 > ! | 123 > ! | 4567890123456789 > ! | -4567890123456789 > (5 rows) > > SELECT '' AS to_char_15, to_char(q2, 'S 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 . 9 9 9') >FROM INT8_TBL; > --- 245,256 > > SELECT '' AS to_char_14, to_char(q2, 'FM.999') FROM INT8_TBL; >to_char_14 | to_char > ! + > ! | 456. > ! | 4567890123456789. > ! | 123. > ! | 4567890123456789. > ! | -4567890123456789. > (5 rows) > > SELECT '' AS to_char_15, to_char(q2, 'S 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 . 9 9 9') >FROM INT8_TBL; > > == > > *** ./expected/numeric.outFri Apr 7 15:17:42 2000 > --- ./results/numeric.out Fri Sep 20 12:37:36 2002 > *** > *** 785,792 > | +7799461.4119 > | +16397.038491 > | +93901.57763026 > !| -83028485 > !| +74881 > | -24926804.04504742 > (10 rows) > > --- 785,792 > | +7799461.4119 > | +16397.038491 > | +93901.57763026 > !| -83028485. > !| +74881. > | -24926804.04504742 > (10 rows) > > *** > *** 800,807 > | 7799461.4119 > | 16397.038491 > | 93901.57763026 > !| <83028485> > !| 74881 > | <24926804.04504742> > (10 rows) > > --- 800,807 > | 7799461.4119 > | 16397.038491 > | 93901.57763026 > !| <83028485.> > !| 74881. > | <24926804.04504742> > (10 rows) > > *** > *** 860,867 > | 07799461.4119 > | 00016397.038491 > | 00093901.57763026 > ! | -83028485 > ! | 00074881 > | -24926804.04504742 > (10 rows) > > --- 860,867 > | 07799461.4119 > | 00016397.038491 > | 00093901.57763026 > ! | -83028485. > ! | 00074881. > | -24926804.04504742 > (10 rows) > > *** > *** 950,957 > | 7799461.4119 > | 16397.038491 > | 93901.57763026 > ! | -83028485 > ! | 74881 > | -24926804.04504742 > (10 rows) > > --- 950,957 > | 7799461.4119 > | 16397.038491 > | 93901.57763026 > ! | -83028485. > ! | 74881. > | -24926804.04504742 > (10 rows) > > *** > *** 980,987 > | + 7 7 9 9 4 6 1 . 4 1 1 9 > | + 1 6 3 9 7 . 0 3 8 4 9 1 > | + 9 3 9 0 1 . 5 7 7 6 3 0 2 6 > ! | -8 3 0 2 8 4 8 5 > ! | + 7 4 8 8 1 > | -2 4 9 2 6 8 0 4 . 0 4 5 0 4 7 4 2 > (10 rows) > > --- 980,987 > | + 7 7 9 9 4 6 1 . 4 1 1 9 > | + 1 6 3 9 7 . 0 3 8 4 9 1 > | + 9 3 9 0 1 . 5 7 7 6 3 0 2 6 > ! | -8 3 0 2 8 4 8 5 . > ! | + 7 4 8 8 1 . > | -2 4 9 2 6 8 0 4 . 0 4 5 0 4 7 4 2 > (10 rows) > > *** > *** 1025,1032 > | 7799461.4119 > | 16397.038491 > | 93901.57763026 > ! | -83028485 > ! | 74881 > | -24926804.04504742 > (10 rows) > > --- 1025,1032 > | 7799461.4119 > | 16397.038491 > | 93901.57763026 > ! | -83028485. > ! | 74881. > | -24926804.04504742 > (10 rows) > > > ===
[HACKERS] regression test failure in CVS HEAD
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 2001 --- ./results/int8.out Fri Sep 20 12:37:25 2002 *** *** 245,256 SELECT '' AS to_char_14, to_char(q2, 'FM.999') FROM INT8_TBL; to_char_14 | to_char ! +--- ! | 456 ! | 4567890123456789 ! | 123 ! | 4567890123456789 ! | -4567890123456789 (5 rows) SELECT '' AS to_char_15, to_char(q2, 'S 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 . 9 9 9') FROM INT8_TBL; --- 245,256 SELECT '' AS to_char_14, to_char(q2, 'FM.999') FROM INT8_TBL; to_char_14 | to_char ! + ! | 456. ! | 4567890123456789. ! | 123. ! | 4567890123456789. ! | -4567890123456789. (5 rows) SELECT '' AS to_char_15, to_char(q2, 'S 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 . 9 9 9') FROM INT8_TBL; == *** ./expected/numeric.out Fri Apr 7 15:17:42 2000 --- ./results/numeric.out Fri Sep 20 12:37:36 2002 *** *** 785,792 | +7799461.4119 | +16397.038491 | +93901.57763026 !| -83028485 !| +74881 | -24926804.04504742 (10 rows) --- 785,792 | +7799461.4119 | +16397.038491 | +93901.57763026 !| -83028485. !| +74881. | -24926804.04504742 (10 rows) *** *** 800,807 | 7799461.4119 | 16397.038491 | 93901.57763026 !| <83028485> !| 74881 | <24926804.04504742> (10 rows) --- 800,807 | 7799461.4119 | 16397.038491 | 93901.57763026 !| <83028485.> !| 74881. | <24926804.04504742> (10 rows) *** *** 860,867 | 07799461.4119 | 00016397.038491 | 00093901.57763026 ! | -83028485 ! | 00074881 | -24926804.04504742 (10 rows) --- 860,867 | 07799461.4119 | 00016397.038491 | 00093901.57763026 ! | -83028485. ! | 00074881. | -24926804.04504742 (10 rows) *** *** 950,957 | 7799461.4119 | 16397.038491 | 93901.57763026 ! | -83028485 ! | 74881 | -24926804.04504742 (10 rows) --- 950,957 | 7799461.4119 | 16397.038491 | 93901.57763026 ! | -83028485. ! | 74881. | -24926804.04504742 (10 rows) *** *** 980,987 | + 7 7 9 9 4 6 1 . 4 1 1 9 | + 1 6 3 9 7 . 0 3 8 4 9 1 | + 9 3 9 0 1 . 5 7 7 6 3 0 2 6 ! | -8 3 0 2 8 4 8 5 ! | + 7 4 8 8 1 | -2 4 9 2 6 8 0 4 . 0 4 5 0 4 7 4 2 (10 rows) --- 980,987 | + 7 7 9 9 4 6 1 . 4 1 1 9 | + 1 6 3 9 7 . 0 3 8 4 9 1 | + 9 3 9 0 1 . 5 7 7 6 3 0 2 6 ! | -8 3 0 2 8 4 8 5 . ! | + 7 4 8 8 1 . | -2 4 9 2 6 8 0 4 . 0 4 5 0 4 7 4 2 (10 rows) *** *** 1025,1032 | 7799461.4119 | 16397.038491 | 93901.57763026 ! | -83028485 ! | 74881 | -24926804.04504742 (10 rows) --- 1025,1032 | 7799461.4119 | 16397.038491 | 93901.57763026 ! | -83028485. ! | 74881. | -24926804.04504742 (10 rows) == ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] regression test failure
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 $prefix/lib. However I wonder this would break some installations, > > for example RPM. > You can replace the string '$libdir' in the conversions_create.sql file > with an absolute directory name during the standalone regression test run. > This could be done in the regression test driver, where the correct path > is available as $pkglibdir. Other, less messy solutions don't occur to me > offhand. The RPM's patch the regression tests to work -- in a somewhat broken way, but enough to get useful results. IIRC, I'm already subbing $libdir out in them. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] regression test failure
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 installations, > for example RPM. You can replace the string '$libdir' in the conversions_create.sql file with an absolute directory name during the standalone regression test run. This could be done in the regression test driver, where the correct path is available as $pkglibdir. Other, less messy solutions don't occur to me offhand. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] regression test failure
[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 know if you need any more information. Do you still have the failure after doing "make install"? If so, it's news to me. If not, it's a known problem I want to fix before the beta freeze. The basic problem here is I'm using following statement while doing initdb: CREATE OR REPLACE FUNCTION utf8_to_iso8859_1 (INTEGER, INTEGER, OPAQUE, OPAQUE, INTEGER) RETURNS INTEGER AS '$libdir/utf8_and_iso8859_1', 'utf8_to_iso8859_1' LANGUAGE 'c'; 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 installations, for example RPM. Any idea? -- Tatsuo Ishii ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
