Thread: regress test failed
Hello
there is one regress test, that failed on my f14
[pavel@nemesis postgresql]$ uname -a
Linux nemesis 2.6.35.14-95.fc14.i686.PAE #1 SMP Tue Aug 16 21:12:22
UTC 2011 i686 i686 i386 GNU/Linux
regression.diffs
3676/3676 100%
*** /home/pavel/src/postgresql/src/test/regress/expected/foreign_data.out 2011-09-04 14:17:23.463589991 +0200
--- /home/pavel/src/postgresql/src/test/regress/results/foreign_data.out 2011-09-04 14:20:06.649144130 +0200
***************
*** 781,791 **** SELECT * FROM information_schema.foreign_servers ORDER BY 1, 2; foreign_server_catalog |
foreign_server_name|
foreign_data_wrapper_catalog | foreign_data_wrapper_name |
foreign_server_type | foreign_server_version |
authorization_identifier
------------------------+---------------------+------------------------------+---------------------------+---------------------+------------------------+--------------------------
regression | s4 | regression | foo | oracle |
| foreign_data_user regression | s5 | regression | foo |
| 15.0 | regress_test_role regression | s6 | regression
| foo | | 16.0 | regress_test_indirect regression | s8
| regression | postgresql | | | foreign_data_user
- regression | sc | regression | dummy | |
| foreign_data_user regression | t1 | regression | foo
| | | regress_test_indirect regression | t2 | regression
| foo | | | regress_test_role (7 rows)
--- 781,791 ---- SELECT * FROM information_schema.foreign_servers ORDER BY 1, 2; foreign_server_catalog |
foreign_server_name|
foreign_data_wrapper_catalog | foreign_data_wrapper_name |
foreign_server_type | foreign_server_version |
authorization_identifier
------------------------+---------------------+------------------------------+---------------------------+---------------------+------------------------+--------------------------
+ regression | sc | regression | dummy | |
| foreign_data_user regression | s4 | regression | foo
| oracle | | foreign_data_user regression | s5 | regression
|foo | | 15.0 | regress_test_role regression | s6
| regression | foo | | 16.0 |
regress_test_indirect regression | s8 | regression | postgresql |
| | foreign_data_user regression | t1 | regression | foo
| | | regress_test_indirect regression | t2
| regression | foo | | | regress_test_role (7 rows)
tested on HEAD
regards
Pavel Stehule
On 09/04/2011 08:23 AM, Pavel Stehule wrote: > Hello > > there is one regress test, that failed on my f14 > > [pavel@nemesis postgresql]$ uname -a > Linux nemesis 2.6.35.14-95.fc14.i686.PAE #1 SMP Tue Aug 16 21:12:22 > UTC 2011 i686 i686 i386 GNU/Linux > > regression.diffs > > 3676/3676 100% > *** /home/pavel/src/postgresql/src/test/regress/expected/foreign_data.out > 2011-09-04 14:17:23.463589991 +0200 > --- /home/pavel/src/postgresql/src/test/regress/results/foreign_data.out > 2011-09-04 14:20:06.649144130 +0200 > *************** > *** 781,791 **** > SELECT * FROM information_schema.foreign_servers ORDER BY 1, 2; > foreign_server_catalog | foreign_server_name | > foreign_data_wrapper_catalog | foreign_data_wrapper_name | > foreign_server_type | foreign_server_version | > authorization_identifier > ------------------------+---------------------+------------------------------+---------------------------+---------------------+------------------------+-------------------------- > regression | s4 | regression > | foo | oracle | > | foreign_data_user > regression | s5 | regression > | foo | | 15.0 > | regress_test_role > regression | s6 | regression > | foo | | 16.0 > | regress_test_indirect > regression | s8 | regression > | postgresql | | > | foreign_data_user > - regression | sc | regression > | dummy | | > | foreign_data_user > regression | t1 | regression > | foo | | > | regress_test_indirect > regression | t2 | regression > | foo | | > | regress_test_role > (7 rows) > --- 781,791 ---- > SELECT * FROM information_schema.foreign_servers ORDER BY 1, 2; > foreign_server_catalog | foreign_server_name | > foreign_data_wrapper_catalog | foreign_data_wrapper_name | > foreign_server_type | foreign_server_version | > authorization_identifier > ------------------------+---------------------+------------------------------+---------------------------+---------------------+------------------------+-------------------------- > + regression | sc | regression > | dummy | | > | foreign_data_user > regression | s4 | regression > | foo | oracle | > | foreign_data_user > regression | s5 | regression > | foo | | 15.0 > | regress_test_role > regression | s6 | regression > | foo | | 16.0 > | regress_test_indirect > regression | s8 | regression > | postgresql | | > | foreign_data_user > regression | t1 | regression > | foo | | > | regress_test_indirect > regression | t2 | regression > | foo | | > | regress_test_role > (7 rows) > > tested on HEAD > > In what locale does 'sc' sort before 's4'? (And I'd humbly suggest that whatever locale it is is possibly broken.) cheers andrew
On 09/04/2011 08:57 AM, Andrew Dunstan wrote: > In what locale does 'sc' sort before 's4'? (And I'd humbly suggest that > whatever locale it is is possibly broken.) EBCDIC? Joe
On sön, 2011-09-04 at 08:57 -0400, Andrew Dunstan wrote: > In what locale does 'sc' sort before 's4'? In Czech. > (And I'd humbly suggest that whatever locale it is is possibly > broken.) There were some discussions about this in the past; it's apparently based on a national standard and completely valid.
On 09/04/2011 10:23 AM, Peter Eisentraut wrote: > On sön, 2011-09-04 at 08:57 -0400, Andrew Dunstan wrote: >> In what locale does 'sc' sort before 's4'? > In Czech. > >> (And I'd humbly suggest that whatever locale it is is possibly >> broken.) > There were some discussions about this in the past; it's apparently > based on a national standard and completely valid. > Well, I don't think we are obliged to cater for locales that break ASCII ordering. (There's a reason the buildfarm client runs its first set of checks in C locale). And to answer Pavel's question in email to me (maybe he meant to hit reply-all instead of reply): > This order is based on czech locale, but regress tests should be > independent on locale? > No, it's not really possible. Something has to determine sort order. cheers andrew
On sön, 2011-09-04 at 10:47 -0400, Andrew Dunstan wrote: > Well, I don't think we are obliged to cater for locales that break ASCII > ordering. We do cater for that. See commit 8cd375526790c5be8ae24c77f13ac446adda88b6 Author: Peter Eisentraut <peter_e@gmx.net> Date: Mon Mar 9 15:04:21 2009 +0000 Tweak the regression test case so that the ordering of numbers vs. letters doesn't matter. This fixes failures in theCzech locale. commit 71936fc5eb6330ace4205163b3d2f731a7db5a41 Author: Peter Eisentraut <peter_e@gmx.net> Date: Thu Feb 12 15:11:44 2009 +0000 The Czech (cs_CZ) and Slovak (sk_SK) locales sort numbers after letters, instead of vice versa. Update the regressiontest expectations to support that. In the plpgsql test, adjust the test data so that this isn't an issue. In the char and varchar tests, add new expected files. and more generally commit 8987c115f1e7256b17c1cd04a8471810185d1941 Author: Peter Eisentraut <peter_e@gmx.net> Date: Mon Jan 19 13:38:47 2009 +0000 Alter regression test cases that rely on the sort order of "aa". Some locales (da_DK, fo_FO, kl_GL, nb_NO, nn_NO inglibc) sort "aa" after "z". commit 2b01cbe34042ed9fdea38a0c2fad5ab81df032c9 Author: Peter Eisentraut <peter_e@gmx.net> Date: Mon Jan 19 12:02:29 2009 +0000 Alter the regression test cases that rely on the sort order of "ch" between "cg" and "ci". This eliminates a test failureon the following glibc locales: br_FR, cs_CZ, cy_GB, es_EC, es_US, hsb_DE, ig_NG, ik_CA, sk_SK. commit a5d67a0a050a9d32c351183992c3f08631735c37 Author: Peter Eisentraut <peter_e@gmx.net> Date: Sun Jan 11 09:41:45 2009 +0000 Make tests pass with or without locale. > And to answer Pavel's question in email to me (maybe he meant to hit > reply-all instead of reply): > > > This order is based on czech locale, but regress tests should be > > independent on locale? > > > > No, it's not really possible. Something has to determine sort order. Well, if the going gets tough, we could stick a COLLATE "C" here and there. But as you can see above, this case should work. If something broke it, let's fix it.
Andrew Dunstan <andrew@dunslane.net> writes:
> On 09/04/2011 10:23 AM, Peter Eisentraut wrote:
>> On sön, 2011-09-04 at 08:57 -0400, Andrew Dunstan wrote:
> In what locale does 'sc' sort before 's4'?
>> In Czech.
> Well, I don't think we are obliged to cater for locales that break ASCII
> ordering.
We've changed regression test cases to avoid this type of problem in the
past. I see no reason not to do it here. The object "sc" could just as
easily be named something else.
regards, tom lane
Andrew Dunstan <andrew@dunslane.net> writes:
> Well, I don't think we are obliged to cater for locales that break ASCII
> ordering.
The logical conclusion of that position is that there's no need to make
the regression tests pass in any other locale than C. Which is not the
project policy, and we (including you, with your buildfarm hat on) have
expended plenty of sweat in support of that.
I think the real question that needs to be asked here is why there's not
a buildfarm member running the tests in Czech locale. And maybe some
of the other ones that have been problematic in the past. We should not
have to wait for random reports to find out about this.
regards, tom lane
On 09/04/2011 11:31 AM, Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.net> writes: >> Well, I don't think we are obliged to cater for locales that break ASCII >> ordering. > The logical conclusion of that position is that there's no need to make > the regression tests pass in any other locale than C. Which is not the > project policy, and we (including you, with your buildfarm hat on) have > expended plenty of sweat in support of that. I thought that was more about things like letters with diacritical marks, Turkish i and so on. But I stand corrected. > I think the real question that needs to be asked here is why there's not > a buildfarm member running the tests in Czech locale. And maybe some > of the other ones that have been problematic in the past. We should not > have to wait for random reports to find out about this. > Maybe we need a few members that test a large number of locales. (Anyone feel like donating resources? I'm currently providing resources for seven, which I think is sufficient :-) ) Or a few volunteers from among existing members that can test lots of locales. (My f14 box has 245 utf8 locales, 181 non-utf8 locales and 308 that don't specify an encoding. Or I could make the client get a list of available locales/encodings and then test a number of them each run cyclically. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> On 09/04/2011 11:31 AM, Tom Lane wrote:
>> I think the real question that needs to be asked here is why there's not
>> a buildfarm member running the tests in Czech locale. And maybe some
>> of the other ones that have been problematic in the past. We should not
>> have to wait for random reports to find out about this.
> Maybe we need a few members that test a large number of locales. (Anyone
> feel like donating resources? I'm currently providing resources for
> seven, which I think is sufficient :-) )
> Or a few volunteers from among existing members that can test lots of
> locales. (My f14 box has 245 utf8 locales, 181 non-utf8 locales and 308
> that don't specify an encoding.
I'm not ready to buy into the position that we should make the
regression tests pass on every last locale definition that anyone can
find. That's probably impossible, and certainly more trouble than it'd
be worth. I suspect there's only a dozen or two that need to get
tested.
But I would suggest that this could be the policy: don't complain about
regression tests failing in a locale unless you're prepared to support a
buildfarm member that tests that locale on a routine basis.
regards, tom lane
On Sun, Sep 04, 2011 at 09:39:39AM -0400, Joe Abbate wrote: > On 09/04/2011 08:57 AM, Andrew Dunstan wrote: > > In what locale does 'sc' sort before 's4'? (And I'd humbly suggest that > > whatever locale it is is possibly broken.) > > EBCDIC? If you have any EBCDIC machines for the buildfarm, that'd be great :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On sön, 2011-09-04 at 12:06 -0400, Andrew Dunstan wrote: > Maybe we need a few members that test a large number of locales. > (Anyone feel like donating resources? I'm currently providing > resources for seven, which I think is sufficient :-) ) If we're just testing different configuration combinations (as opposed to different operating systems and architectures), we could also consider running this off some cloud provider. That way, we could add dozens of members for $20 a month or so.