Re: check fails on Fedora 23
От | Thomas Munro |
---|---|
Тема | Re: check fails on Fedora 23 |
Дата | |
Msg-id | CAEepm=21b-6khCvCrYeFd_yCEumcO4VyZU1zO-uJaOa5V9HT+Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: check fails on Fedora 23 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: check fails on Fedora 23
|
Список | pgsql-hackers |
On Wed, Oct 7, 2015 at 9:49 AM, Robert Haas <robertmhaas@gmail.com> wrote: > 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 wonder if Glibc bug 18589 is relevant. Bug 18934 says "Note that these unittests pass with glibc-2.21 but fail with 2.22 and current git due to bug 18589 which points to a broken change in the collate algorithm that needs to be reverted first." Hungarian is mentioned. Doesn't Fedora 23 include glibc-2.22? Is it possible that that bug affects strcoll but not strxfrm? https://sourceware.org/bugzilla/show_bug.cgi?id=18589 https://sourceware.org/bugzilla/show_bug.cgi?id=18934 -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: