Thread: 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.

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": Success
> 
> The 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

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

> 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.