Re: [HACKERS] regression failures on WIndows in machines with some non-English
Tom Lane wrote: The simple solution seems to be to add --no-locale to the initdb args in pg_regress.sh. Er ... what exactly does that do that setting LC_ALL=C doesn't? Windows are ignoring locale enviroment variables so you can't do that -- Regards Petr Jelinek (PJMODOS) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] regression failures on WIndows in machines with some non-English locales
Andrew Dunstan <[EMAIL PROTECTED]> writes: > The simple solution seems to be to add --no-locale to the initdb args in > pg_regress.sh. Er ... what exactly does that do that setting LC_ALL=C doesn't? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] regression failures on WIndows in machines with some non-English locales
I have become aware that regression is failing due to ordering differences on Windows machines in some non-English locales (specifically, Czech, but the potential is there for more failures). The problem seems to be that the regression suite and initdb don't do enough between them to ensure that the tests are run in C locale. The simple solution seems to be to add --no-locale to the initdb args in pg_regress.sh. I have asked Petr Jelinek (one of our Czech users) to test this. If it works as I expect it to (buildfarm has done this for installcheck tests for some time) I'd like to add this to both the HEAD and 8.0 branches. I know it's very late in the cycle, but it seems very low risk to me, and I'd like to have regression working on as broad a set of platforms as possible. If people prefer, I could add it just for the Windows case - Unix platforms won't see the effect I propose to remedy, as their setlocale works from the environment, unlike Windows. Thoughts? cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Regression failures: time, timetz, horology
Tom Lane wrote: > Michael Fuhr <[EMAIL PROTECTED]> writes: > > I'm getting time, timetz, and horology regression failures in HEAD > > on Solaris 9 / gcc 3.4.2. So are other machines in the build farm, > > such as this one: > > I'll bet a nickel this broke it: > > 2005-05-25 23:48 momjian > > * src/: backend/utils/adt/datetime.c, > interfaces/ecpg/pgtypeslib/interval.c: Display only 9 not 10 digits > of precision for timestamp values when using non-integer > timestamps. This prevents the display of rounding errors for > common values like days < 32. Yea, backing out. I thought I tested it, but I guess not. -- 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 + 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 failures: time, timetz, horology
Michael Fuhr <[EMAIL PROTECTED]> writes: > I'm getting time, timetz, and horology regression failures in HEAD > on Solaris 9 / gcc 3.4.2. So are other machines in the build farm, > such as this one: I'll bet a nickel this broke it: 2005-05-25 23:48 momjian * src/: backend/utils/adt/datetime.c, interfaces/ecpg/pgtypeslib/interval.c: Display only 9 not 10 digits of precision for timestamp values when using non-integer timestamps. This prevents the display of rounding errors for common values like days < 32. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Regression failures: time, timetz, horology
I'm getting time, timetz, and horology regression failures in HEAD on Solaris 9 / gcc 3.4.2. So are other machines in the build farm, such as this one: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=shark&dt=2005-05-26%2004:21:00 I'm getting the same regression failures shown in that link; here's an example: *** *** 34,45 SELECT f1 AS "Five" FROM TIME_TBL WHERE f1 > '05:06:07'; Five ! - 11:59:00 12:00:00 12:01:00 23:59:00 ! 23:59:59.99 (5 rows) SELECT f1 AS "None" FROM TIME_TBL WHERE f1 < '00:00'; --- 34,45 SELECT f1 AS "Five" FROM TIME_TBL WHERE f1 > '05:06:07'; Five ! -- 11:59:00 12:00:00 12:01:00 23:59:00 ! 23:59:59.990 (5 rows) SELECT f1 AS "None" FROM TIME_TBL WHERE f1 < '00:00'; -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Regression failures on freebsd
On Thu, Apr 14, 2005 at 09:52:11AM +0800, Christopher Kings-Lynne wrote: > > I did 'gmake distclean' and rebuild and I still get the attached failures. What versions of PostgreSQL and FreeBSD? The FreeBSD machines in the buildfarm look good. http://www.pgbuildfarm.org/cgi-bin/show_status.pl If you're using CVS, have you tried with a fresh checkout? What command do you run when you update? If you have a ~/.cvsrc, what's in it? Do you update into a distclean'ed directory, or into one that still has an old build in it? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Regression failures on freebsd
Do you build in a separate directory? I do and I do have problems when the grammars (main or plpgsql) get updated -- not sure why the derived files from bison and flex don't get rebuilt. I just delete them by hand. (The build directory I just rm -fr as a whole). Yours doesn't seem like a problem in grammars, but who knows. No, I do a normal in-place build. Chris ---(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 failures on freebsd
On Thu, Apr 14, 2005 at 09:52:11AM +0800, Christopher Kings-Lynne wrote: > I did 'gmake distclean' and rebuild and I still get the attached failures. Do you build in a separate directory? I do and I do have problems when the grammars (main or plpgsql) get updated -- not sure why the derived files from bison and flex don't get rebuilt. I just delete them by hand. (The build directory I just rm -fr as a whole). Yours doesn't seem like a problem in grammars, but who knows. What I do is cd $source_dir for i in `find . -name .cvsignore`; do pushd `dirname $i` rm `cat .cvsignore` popd done -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Si quieres ser creativo, aprende el arte de perder el tiempo" ---(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
[HACKERS] Regression failures on freebsd
I did 'gmake distclean' and rebuild and I still get the attached failures. Chris parallel group (13 tests): text name char varchar boolean oid int8 int2 float4 int4 float8 bit numeric boolean ... ok char ... ok name ... ok varchar ... ok text ... ok int2 ... ok int4 ... ok int8 ... ok oid ... ok float4 ... ok float8 ... ok bit ... ok numeric ... ok test strings ... ok test numerology ... ok parallel group (20 tests): comments lseg time timetz circle reltime path tinterval abstime point box polygon inet type_sanity timestamptz timestamp date oidjoins interval opr_sanity point... ok lseg ... ok box ... ok path ... ok polygon ... ok circle ... ok date ... ok time ... ok timetz ... ok timestamp... ok timestamptz ... ok interval ... ok abstime ... ok reltime ... ok tinterval... ok inet ... ok comments ... ok oidjoins ... ok type_sanity ... ok opr_sanity ... ok test geometry ... ok test horology ... ok test insert ... ok test create_function_1... ok test create_type ... ok test create_table ... ok test create_function_2... ok test copy ... ok parallel group (7 tests): create_operator create_aggregate vacuum triggers constraints inherit create_misc constraints ... ok triggers ... FAILED create_misc ... ok create_aggregate ... ok create_operator ... ok inherit ... ok vacuum ... ok parallel group (2 tests): create_view create_index create_index ... ok create_view ... ok test sanity_check ... ok test errors ... ok test select ... ok parallel group (18 tests): select_distinct_on select_into random update namespace select_distinct btree_index hash_index select_having select_implicit case aggregates union subselect arrays join portals transactions select_into ... ok select_distinct ... ok select_distinct_on ... ok select_implicit ... ok select_having... ok subselect... ok union... ok case ... ok join ... ok aggregates ... ok transactions ... ok random ... ok portals ... ok arrays ... ok btree_index ... ok hash_index ... ok update ... ok namespace... ok test privileges ... ok test misc ... ok parallel group (5 tests): portals_p2 select_views cluster foreign_key rules select_views ... ok portals_p2 ... ok rules... ok foreign_key ... ok cluster ... ok parallel group (14 tests): limit prepare sequence rowtypes truncate polymorphism copy2 without_oid temp conversion domain rangefuncs alter_table plpgsql limit... ok plpgsql ... ok copy2... FAILED temp ... ok domain ... FAILED rangefuncs ... ok prepare ... ok without_oid ... ok conversion ... ok truncate ... ok alter_table ... FAILED sequence ... ok polymorphism ... ok rowtypes ... ok test stats... ok test tablespace ... ok *** ./expected/triggers.out Wed Oct 13 09:22:31 2004 --- ./results/triggers.out Thu Apr 14 09:38:13 2005 *** *** 307,315 NOTICE: trigger_func() called: action = UPDATE, when = AFTER, level = STATEMENT -- COPY should fire per-row and per-statement INSERT triggers COPY main_table (a, b) FROM stdin; NOTICE: trigger_func() called: action = INSERT, when = BEFORE, level = STATEMENT NOTICE: trigger_func() called: action = INSERT, when = AFTER, level = STATEMENT - SELECT * FROM main_table ORDER BY a, b; a | b + 6 | 10 --- 307,315 NOTICE: trigger_func() called: action = UPDATE, when = AFTER, level = STATEMENT -- COPY should fire per-row and per-statement INSERT triggers COPY main_table (a, b) FROM stdin; + SELECT * FROM main_table ORDER BY a, b; NOTICE:
Re: [HACKERS] regression failures
OK, regression tests adjusted and cat version updated. --- Tom Lane wrote: > Joe Conway <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> There should have been a catversion bump for the domain-constraints > >> patch, but there wasn't. When was your previous CVS pull? > > > Several days ago at least. > > Then you probably got bit by that patch --- it was applied a couple days > ago. > > > I use cvsup every few days to sync up. Is there a > > way I can tell exactly when? > > Dunno, I don't use cvsup. > > 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 > -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] regression failures
Joe Conway <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> There should have been a catversion bump for the domain-constraints >> patch, but there wasn't. When was your previous CVS pull? > Several days ago at least. Then you probably got bit by that patch --- it was applied a couple days ago. > I use cvsup every few days to sync up. Is there a > way I can tell exactly when? Dunno, I don't use cvsup. 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 failures
Tom Lane wrote: There should have been a catversion bump for the domain-constraints patch, but there wasn't. When was your previous CVS pull? Several days ago at least. I use cvsup every few days to sync up. Is there a way I can tell exactly when? Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] regression failures
Joe Conway <[EMAIL PROTECTED]> writes: > I guess a recent change requires an initdb but no change was forced? There should have been a catversion bump for the domain-constraints patch, but there wasn't. When was your previous CVS pull? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] regression failures
On Sat, 2002-11-23 at 01:04, Joe Conway wrote: > I'm getting lots of regression failures: > > > 25 of 89 tests failed. > > > all pretty much looking like: > >SELECT '' AS one, o.* FROM OID_TBL o WHERE o.f1 = 1234; > ! ERROR: Relation "pg_constraint_contypid_index" does not exist >SELECT '' AS five, o.* FROM OID_TBL o WHERE o.f1 <> '1234'; > > I guess a recent change requires an initdb but no change was forced? > (...an initdb does in fact fix the problem -- now only the "misc" test fails) You're right. I added an index to pg_constraint and had completely forgotten about it. Sorry. Could someone bump CATALOG_VERSION_NO? -- Rod Taylor <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] regression failures
I'm getting lots of regression failures: 25 of 89 tests failed. all pretty much looking like: SELECT '' AS one, o.* FROM OID_TBL o WHERE o.f1 = 1234; ! ERROR: Relation "pg_constraint_contypid_index" does not exist SELECT '' AS five, o.* FROM OID_TBL o WHERE o.f1 <> '1234'; I guess a recent change requires an initdb but no change was forced? (...an initdb does in fact fix the problem -- now only the "misc" test fails) Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
