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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
Cc: "Peter Geoghegan" <pg(at)bowt(dot)ie>, "PostgreSQL mailing lists" <pgsql-bugs(at)postgresql(dot)org>, "Peter Eisentraut" <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Subject: Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Date: 2017-08-06 03:26:28
Message-ID: 10186.1501989988@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

"Daniel Verite" <daniel(at)manitou-mail(dot)org> writes:
> If someone wants to reproduce the problem, I've made
> a custom dump (40MB) available at
> http://www.manitou-mail.org/vrac/words_test.dump

Thanks for providing this test data. I've attempted, so far
unsuccessfully, to reproduce the crash. I'm using today's HEAD PG code,
in --enable-debug --enable-cassert configuration, all parameters default
except work_mem = 128MB. I see no crash with any ICU collation provided
by these configurations:

* RHEL 6's stock version of ICU 4.2, on x86_64

* Direct-from-upstream-source build of icu4c-57_1-src.tgz on
current macOS, also x86_64.

So while that isn't helping all that much, it seems to constrain the range
of affected ICU versions further than we knew before.

I'm quite disturbed though that the set of installed collations on these
two test cases seem to be entirely different both from each other and from
what you reported. The base collations look generally similar, but the
"keyword variant" versions are not comparable at all. Considering that
the entire reason we are interested in ICU in the first place is its
alleged cross-version collation behavior stability, this gives me the
exact opposite of a warm fuzzy feeling. We need to understand why it's
like that and what we can do to reduce the variation, or else we're just
buying our users enormous future pain. At least with the libc collations,
you can expect that if you have en_US.utf8 available today you will
probably still have en_US.utf8 available tomorrow. I am not seeing any
reason to believe that the same holds for ICU collations.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Noah Misch 2017-08-06 06:26:34 Re: Replication to Postgres 10 on Windows is broken
Previous Message Peter Geoghegan 2017-08-05 23:28:59 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul A Jungwirth 2017-08-06 06:03:26 Re: pg_stop_backup(wait_for_archive := true) on standby server
Previous Message Robert Haas 2017-08-06 01:24:37 Re: modeling parallel contention (was: Parallel Append implementation)