Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values
От | Tom Lane |
---|---|
Тема | Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values |
Дата | |
Msg-id | 31926.1502126346@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values
|
Список | pgsql-bugs |
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > On 8/7/17 11:17, Peter Eisentraut wrote: >> I can confirm that that avoids the crash in ICU 52, so it's something to >> consider. We would need more testing about which other ICU versions are >> affected, however. > In my testing, there are no crashes in ICU 51 and ICU 53, so we could > restrict this workaround to version 52 specifically. Perhaps someone > else can confirm my test results. I did some desultory comparison of this source code in ICU 51.2, 52.1, and 53.1. The crash-related code fragments are not significantly different in 51.2 and 52.1. It may be that 52's problem is triggered by broken collation data that wasn't broken in previous versions ... but I have to say that I don't find 51 worthy of trust either. It seems quite likely that pre-52 can still be made to crash, we just don't yet have a test case that triggers it. In 53, they have thrown away ucol.cpp lock stock and barrel, and rewritten the whole thing from scratch in C++. So it's not surprising that these bugs are gone. (Whether it's got other bugs is hard to tell. I do not get the impression, just from eyeballing it, that the code quality went up significantly :-(.) So that explains why upstream is not back-patching fixes for these problems from newer versions: there are no newer versions that they could possibly back-patch from. I'm on board with Peter G's proposal: let's distrust ucol_strcollUTF8 in ICU < 53. If those folk felt a need to rewrite it completely after only three release cycles, that should tell us something. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: