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

From Robert Haas
Subject Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)
Date
Msg-id CA+Tgmobzj8hobNfoVsU0Q7Lva25Oaxr23o8CYWL0Lf7eH5edBg@mail.gmail.com
Whole thread Raw
In response to Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Tue, Mar 22, 2016 at 7:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>>> I was a little worried that it was too much to hope for that all libc
>>> vendors on earth would ship a strxfrm() implementation that was actually
>>> consistent with strcoll(), and here we are.
>
> BTW, the glibc discussion starting here:
> https://sourceware.org/ml/libc-alpha/2015-09/msg00196.html
> should put substantial fear in us about the advisability of putting strxfrm
> results on-disk, as I understand we're now doing in btrees.

No.  Peter proposed that, but it hasn't actually been done.  This
certainly makes that sound inadvisable, though.

We are, however, putting indexes on disk whose ordering was determined
partly by the result of strxfrm() comparisons.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-bugs by date:

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