Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values

On Wed, Aug 2, 2017 at 5:00 AM, Daniel Verite <daniel@manitou-mail.org> wrote:
> Anyway I'll try to build ICU-52 without optimization to avoid these
> <optimized out> parameters.
>
> Also running the same tests with a self-compiled ICU-59 versus debian's
> packaged
> ICU-52 results in *no crash at all*. So maybe the root cause of these crashes
> is
> that a critical fix in ICU has not been backported?

That seems possible. Certainly, there have been a fair amount of
bugfixes against this package, some as recently as April of this year:

http://metadata.ftp-master.debian.org/changelogs/main/i/icu/icu_52.1-8+deb8u5_changelog

I'm sure that you used a version that has the relevant fixes, but it's
not that hard to imagine that new bugs were introduced in the process
of backpatching upstream fixes from later major ICU releases. There
has only been one official ICU point release for 52, which was way
back in 2013. Unofficial backpatches are hazardous in their own way.

> I note that the list of ICU locales available in pg_collation is different
> though.
> When compiled with ICU-59, initdb produces "only" 581 collname
> matching '%icu%', versus 1741 with ICU-52. The ICU version
> is the only thing that differs between both cases.
> But anyway in the list of collations that crash for me with ICU-52, a fair
> number
> (~50) are still there and work in ICU-59, so I think the comparison is still
> meaningful.

I agree that it's a meaningful comparison. It now seems very likely
that this is a bug in ICU, and possibly this particular package. That
seemed likely before now anyway; there is not that much that could go
wrong with PostgreSQL's use of ICU that is peculiar to only a small
minority of available collations. Perhaps you can whittle down your
testcase into something minimal, for the Debian package maintainer.

-- 
Peter Geoghegan