Re: [COMMITTERS] pgsql: Replace empty locale name with implied value in CREATE DATABASE

Lists: pgsql-committerspgsql-hackers
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Replace empty locale name with implied value in CREATE DATABASE
Date: 2012-03-26 01:47:30
Message-ID: E1SBz1u-0000mq-3K@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-committers pgsql-hackers

Replace empty locale name with implied value in CREATE DATABASE and initdb.

setlocale() accepts locale name "" as meaning "the locale specified by the
process's environment variables". Historically we've accepted that for
Postgres' locale settings, too. However, it's fairly unsafe to store an
empty string in a new database's pg_database.datcollate or datctype fields,
because then the interpretation could vary across postmaster restarts,
possibly resulting in index corruption and other unpleasantness.

Instead, we should expand "" to whatever it means at the moment of calling
CREATE DATABASE, which we can do by saving the value returned by
setlocale().

For consistency, make initdb set up the initial lc_xxx parameter values the
same way. initdb was already doing the right thing for empty locale names,
but it did not replace non-empty names with setlocale results. On a
platform where setlocale chooses to canonicalize the spellings of locale
names, this would result in annoying inconsistency. (It seems that popular
implementations of setlocale don't do such canonicalization, which is a
pity, but the POSIX spec certainly allows it to be done.) The same risk
of inconsistency leads me to not venture back-patching this, although it
could certainly be seen as a longstanding bug.

Per report from Jeff Davis, though this is not his proposed patch.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/c7cea267de3ca05b29a57b9d113b95ef3793c8d8

Modified Files
--------------
src/backend/commands/dbcommands.c | 9 +++-
src/backend/utils/adt/pg_locale.c | 34 ++++++++++----
src/bin/initdb/initdb.c | 86 +++++++++++++++++++++++++------------
src/include/utils/pg_locale.h | 2 +-
4 files changed, 90 insertions(+), 41 deletions(-)


From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Replace empty locale name with implied value in CREATE DATABASE
Date: 2012-03-26 08:05:39
Message-ID: 4F702353.1090901@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-committers pgsql-hackers

On 03/26/2012 03:47 AM, Tom Lane wrote:
> Replace empty locale name with implied value in CREATE DATABASE and initdb.
>
> setlocale() accepts locale name "" as meaning "the locale specified by the
> process's environment variables". Historically we've accepted that for
> Postgres' locale settings, too. However, it's fairly unsafe to store an
> empty string in a new database's pg_database.datcollate or datctype fields,
> because then the interpretation could vary across postmaster restarts,
> possibly resulting in index corruption and other unpleasantness.
>
> Instead, we should expand "" to whatever it means at the moment of calling
> CREATE DATABASE, which we can do by saving the value returned by
> setlocale().
>
> For consistency, make initdb set up the initial lc_xxx parameter values the
> same way. initdb was already doing the right thing for empty locale names,
> but it did not replace non-empty names with setlocale results. On a
> platform where setlocale chooses to canonicalize the spellings of locale
> names, this would result in annoying inconsistency. (It seems that popular
> implementations of setlocale don't do such canonicalization, which is a
> pity, but the POSIX spec certainly allows it to be done.) The same risk
> of inconsistency leads me to not venture back-patching this, although it
> could certainly be seen as a longstanding bug.
>
> Per report from Jeff Davis, though this is not his proposed patch.

hmm seems like this commit broken quagga:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2012-03-26%2002%3A03%3A04

Stefan


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Replace empty locale name with implied value in CREATE DATABASE
Date: 2012-03-26 14:29:32
Message-ID: 24880.1332772172@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-committers pgsql-hackers

Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> On 03/26/2012 03:47 AM, Tom Lane wrote:
>> Replace empty locale name with implied value in CREATE DATABASE and initdb.

> hmm seems like this commit broken quagga:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2012-03-26%2002%3A03%3A04

Hm, it's hard to see how that patch would have affected the
create-conversions step but not any preceding one. Can you provide
a stack trace from the core dump?

regards, tom lane


From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Replace empty locale name with implied value in CREATE DATABASE
Date: 2012-03-26 19:06:29
Message-ID: 4F70BE35.3040107@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-committers pgsql-hackers

On 03/26/2012 04:29 PM, Tom Lane wrote:
> Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
>> On 03/26/2012 03:47 AM, Tom Lane wrote:
>>> Replace empty locale name with implied value in CREATE DATABASE and initdb.
>
>> hmm seems like this commit broken quagga:
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2012-03-26%2002%3A03%3A04
>
> Hm, it's hard to see how that patch would have affected the
> create-conversions step but not any preceding one. Can you provide
> a stack trace from the core dump?

hmm weird - I cannot reproduce the core dump using the binaries created
by the failing build at all.
Given that the current build also went through just fine I wonder if
that was some sort of false-alarm created by a cosmic ray or a hardware
issue(though I have no indication that anything is wrong on the box).

Stefan