From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 8.4.0 vs. locales vs. pl/perl? |
Date: | 2009-07-08 17:37:07 |
Message-ID: | 4A54D943.9020405@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Gierth wrote:
> environment: debian packaged 8.4.0
>
> scenario: restoring a dump results in incorrect indexes for some
> specific tables (indexscan order fails to match < comparison or
> order resulting from explicit sorts). The dump contains plperl
> and plperlu language creation and function definitions; excising
> these from the dump removes the problem.
>
> The db locale is en_US.UTF-8 (which appears to be case-insensitive on
> this platform: 'C' > 'd' > 'X'), but the incorrect index ordering that
> results when the full restore is done is consistent with C locale
> (i.e. 'C' > 'X' > 'd').
>
> Looking at the code, the obvious thing that glares out is that the
> locale setup in CheckMyDatabase is calling setlocale rather than
> pg_perm_setlocale... am I missing something, or is this an obvious
> bug?
Looks like an obvious bug. Looking at the archives, it was present in
the collation / per-database locale patches from the beginning, and I
missed it during review. I'll go fix it, thanks for the analysis!
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-07-08 18:16:35 | Does EXEC_BACKEND mode still need to propagate setlocale settings? |
Previous Message | Tom Lane | 2009-07-08 17:31:19 | Re: 8.4.0 vs. locales vs. pl/perl? |