Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Marc-Olaf Jaschke <marc-olaf(dot)jaschke(at)s24(dot)com>, Postgres-Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)
Date: 2016-03-23 16:13:45
Message-ID: 1979.1458749625@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2016-03-23 16:19:02 Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)
Previous Message Tom Lane 2016-03-23 15:43:56 Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2016-03-23 16:16:28 Re: NOT EXIST for PREPARE
Previous Message Michael Meskes 2016-03-23 16:07:00 Re: NOT EXIST for PREPARE