Re: initdb initalization failure for collation "ja_JP"
Marco Atzeri <marco.atzeri@gmail.com>
From: Marco Atzeri <marco.atzeri@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-06-21T16:43:31Z
Lists: pgsql-hackers
On 20/06/2017 17:37, Tom Lane wrote: > I wrote: >> Marco Atzeri <marco.atzeri@gmail.com> writes: >>> Building on Cygwin latest 10 beta1 or head sourece, >>> make check fails as: >>> ... >>> performing post-bootstrap initialization ... 2017-05-31 23:23:22.214 >>> CEST [16860] FATAL: collation "ja_JP" for encoding "EUC_JP" already exists > >> Hmph. Could we see the results of "locale -a | grep ja_JP" ? > > Despite the lack of followup from the OP, I'm pretty troubled by this > report. It shows that the reimplementation of OS collation data import > as pg_import_system_collations() is a whole lot more fragile than the > original coding. We have never before trusted "locale -a" to not produce > duplicate outputs, not since the very beginning in 414c5a2e. AFAICS, > the current coding has also lost the protections we added very shortly > after that in 853c1750f; and it has also lost the admittedly rather > arbitrary, but at least deterministic, preference order for conflicting > short aliases that was in the original initdb code. Hi Tom, I raised the duplication issue on the cygwin mailing list, and one of the core developer reports that they saw the same issues on Linux in the past. https://cygwin.com/ml/cygwin/2017-06/msg00253.html > regards, tom lane Regards Marco
Commits
-
Further hacking on ICU collation creation and usage.
- ddb5fdc06863 10.0 landed
-
Rethink behavior of pg_import_system_collations().
- 0b13b2a7712b 10.0 landed