regress test failed

Hello

there is one regress test, that failed on my f14

[pavel(at)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(at)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(at)gmx(dot)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 the Czech locale.

commit 71936fc5eb6330ace4205163b3d2f731a7db5a41
Author: Peter Eisentraut <peter_e(at)gmx(dot)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 regression test 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(at)gmx(dot)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 in glibc) sort "aa" after "z".

commit 2b01cbe34042ed9fdea38a0c2fad5ab81df032c9
Author: Peter Eisentraut <peter_e(at)gmx(dot)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 failure on 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(at)gmx(dot)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(at)dunslane(dot)net> writes:
> On 09/04/2011 10:23 AM, Peter Eisentraut wrote:
>> On sn, 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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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.