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

From David G. Johnston
Subject Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)
Date
Msg-id CAKFQuwabewVUoXYM6zavRuGyuMOJhufPv23Nu0mx4CmSXnJ3FQ@mail.gmail.com
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)
List pgsql-bugs
On Wed, Mar 23, 2016 at 9:13 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> 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.
>

Is the POSIX/C (non)-locale affected?

David J.

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: Robert Haas
Date:
Subject: Re: Breakage with VACUUM ANALYSE + partitions