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

From Peter Geoghegan
Subject Re: [BUGS] Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)
Date
Msg-id CAM3SWZR8YQYP18VoHmeG-VsabGxWKkiCWO_Cc0bbHNDYyezmHA@mail.gmail.com
Whole thread Raw
Responses Re: Re: [BUGS] Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On Wed, Mar 23, 2016 at 10:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Are you still in information-gathering more, or are you going to issue
>> a recommendation on how we should proceed here, or what?
>
> If I had to make a recommendation right now, I would go for your
> option #4, ie shut 'em all down Scotty.  We do not know the full extent
> of the problem but it looks pretty bad, and I think our first priority
> has to be to guarantee data integrity.  I do not have a lot of faith in
> the proposition that glibc's is the only buggy implementation, either.

For the record, I have been able to determine by using amcheck on the
Heroku platform that en_US.UTF-8 cases are sometimes affected by an
inconsistency between strcoll() and strxfrm() behavior, which was
previously an open question. I saw only two instances of this across
many thousands of servers. For some reason, both cases involved
strings with code points from the Arabic alphabet, even though each
case was from a totally unrelated customer database.

I'll go update the Wiki page for this [1] now.

[1] https://wiki.postgresql.org/wiki/Abbreviated_keys_glibc_issue
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [PATCH] Transaction traceability - txid_status(bigint)
Next
From: Tom Lane
Date:
Subject: Better locale-specific-character-class handling for regexps