Re: check fails on Fedora 23 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: check fails on Fedora 23
Date
Msg-id CA+Tgmob_4f+C3u9H6oPoF0vDL7OSXCPOYt2DPHw+HZSN6thQow@mail.gmail.com
Whole thread Raw
In response to Re: check fails on Fedora 23  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: check fails on Fedora 23  (Thomas Munro <thomas.munro@enterprisedb.com>)
Re: check fails on Fedora 23  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> Isn't this arguably a Fedora regression? What did they change in F23 to make
> it fail? I note that F23 is still in Beta.

Maybe, but it's pretty unfriendly for us to complain about a library
issue, if it is one, by failing an Assert().  People with
non-assert-enabled builds will just get wrong answers.  Yuck.

Thinking about how this could happen, I believe that one possibility
is that there are two strings A and B and a locale L such that
strcoll_l(A, B, L) and memcmp(strxfrm(A, L), strxfrm(B, L)) disagree
(that is, the results are of different sign, or one is zero and the
other is not).

I don't have an environment handy to reproduce this, but it would be
nifty if someone could figure out exactly what strings are failing and
then provide the strcoll result and the strxfrm blobs for those
strings.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: about fsync in CLOG buffer write
Next
From: Robert Haas
Date:
Subject: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.