"Daniel Verite" <daniel@manitou-mail.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs