pgsql: Replace empty locale name with implied value in CREATE DATABASE
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(-)
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
Stefan Kaltenbrunner <stefan@kaltenbrunner.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
On 03/26/2012 04:29 PM, Tom Lane wrote:
Stefan Kaltenbrunner <stefan@kaltenbrunner.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%3A04Hm, 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