pg9.4b1: unhelpful error message when creating a collation
sh> lsb_release -d
Description: Ubuntu 14.04 LTS
Codename: trusty
sh> uname -a
Linux sto 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
sh> locale -a
C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
fr_FR.utf8
POSIX
# with postgresql 9.4 installed from apt.postgresql.org.
sql> SELECT VERSION();
PostgreSQL 9.4beta1 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit
sql> \dOS+
+- same list as above with "locale"
sql> SHOW lc_messages;
en_US.UTF-8
# stuff which is working as expected:
sql> CREATE COLLATION "test0" (locale='C');
CREATE COLLATION
sql> CREATE COLLATION "test1" (locale='en_US.UTF-8');
CREATE COLLATION
sql> CREATE COLLATION "test2" (locale='en_US.UTF8');
CREATE COLLATION
sql> CREATE COLLATION "test3" (locale='Foo');
ERROR: could not create locale "test3": No such file or directory
DETAIL: The operating system could not find any locale data for the locale name "Foo".
# stuff which is incoherent:
sql> CREATE COLLATION "french" (locale='fr_FR.utf8');
ERROR: could not create locale "fr_FR.utf8": Success
The collation creation fails, not sure why yet. However, the "error ..
success" message is especially unhelpful.
Raising client_min_messages does not add more information.
I could not get the same error with 9.3.4.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 2014-05-25 09:17:24 +0200, Fabien COELHO wrote:
sql> CREATE COLLATION "french" (locale='fr_FR.utf8');
ERROR: could not create locale "fr_FR.utf8": SuccessThe collation creation fails, not sure why yet. However, the "error ..
success" message is especially unhelpful.
This seems to be a glibc bug. If a nonexistant locale has already been
asked for errno is set to 0 instead of something sensible.
Using a debugger it's possible to see that in an earlier setlocale()
call errno is set correctly, but newlocale() then fails without setting
errno. The culprit seems to be some caching in glibc's _nl_find_locale().
I am not entirely sure why it's not reliably triggered < 9.4.
Searching for that error turned up:
https://sourceware.org/bugzilla/show_bug.cgi?id=14247
https://bugzilla.redhat.com/show_bug.cgi?id=827510
The latter by Tom Lane ;). Unfortunately not much seems to have happened
since.
Except badgering the glibc guys a bit, the only thing I can think of is
to fudge errno = 0 into errno = ENOENT. Not nice.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-05-25 09:17:24 +0200, Fabien COELHO wrote:
sql> CREATE COLLATION "french" (locale='fr_FR.utf8');
ERROR: could not create locale "fr_FR.utf8": Success
This seems to be a glibc bug. If a nonexistant locale has already been
asked for errno is set to 0 instead of something sensible.
Searching for that error turned up:
https://sourceware.org/bugzilla/show_bug.cgi?id=14247
https://bugzilla.redhat.com/show_bug.cgi?id=827510
The latter by Tom Lane ;). Unfortunately not much seems to have happened
since.
Yeah. Red Hat seems to be carrying a patch (the RH bugzilla says it
was fixed in Fedora 17, and I see correct behavior in current RHEL6)
but if the sourceware bug reflects the state of affairs upstream then
other distros may still be suffering from the bug.
Except badgering the glibc guys a bit, the only thing I can think of is
to fudge errno = 0 into errno = ENOENT. Not nice.
Yeah, I don't especially care for adding such a workaround. If the
consequences were worse than a wrong error message, then maybe ---
but adding the workaround might itself sometimes mean a wrong error
message, so it's not clear we'd be making much forward progress.
Better to pester the glibc boys to fix it properly. In the meantime,
you might have some luck asking the Ubuntu packagers to copy Red Hat's
fix.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Searching for that error turned up:
https://sourceware.org/bugzilla/show_bug.cgi?id=14247
https://bugzilla.redhat.com/show_bug.cgi?id=827510
Indeed. Thanks for the pointer.
I have reported the issue on launchpad (ubuntu bug tracking site) with a
link to the redhat bug and Tom's test program attached.
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1323953
We'll see what happens.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers