Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)
Date
Msg-id 1979.1458749625@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-bugs
I wrote:
> I extended my test program to be able to check locales using ISO-8859-x
> encodings.  RHEL6 shows me failures in a set of locales that is remarkably
> unlike the set it fails on for UTF8 (though good ol de_DE manages to fail
> in both encodings, as do a few others).  I'm not sure what that implies
> for the underlying bug(s).

Closer analysis says that all of the cases where only utf8 is reported to
fail are in fact because there is no iso8859 equivalent locale on my
machine.  Many of the cases where only iso8859 is reported to fail are
just chance passes due to not having randomly generated a failure case;
you can reduce the odds of that by passing strcolltest a repeat count
larger than 1.  There remain, however, a few locales in which it seems
that indeed iso8859 is broken and utf8 is not; ru_RU being the most
prominent example.

In short, the problem is actually worse in non-UTF8 locales.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)
Next
From: "David G. Johnston"
Date:
Subject: Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)