From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: check fails on Fedora 23 |
Date: | 2015-10-06 20:49:58 |
Message-ID: | CA+Tgmob_4f+C3u9H6oPoF0vDL7OSXCPOYt2DPHw+HZSN6thQow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-10-06 20:58:08 | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |
Previous Message | Robert Haas | 2015-10-06 20:42:27 | Re: about fsync in CLOG buffer write |