Thread: locale issues on win32 (fix?)

locale issues on win32 (fix?)

From
"Magnus Hagander"
Date:
Hello!

Here is a temp fix for the locale issues on win32. It passes regression
tests, but is *NOT* ready to be applied (if nothing else, it at least
needs more error checking).


The issue is that locale settings were not inherited by the postgres
backends when they were execed... Instead, the locale was reset to
whatever the system default was. I have a few questions before I
continue fixing up the patch, though:

* Is it enough to explicitly store/save LC_COLLATE and LC_CTYPE, or does
more of the locale stuff need to be stored? I think the rest is handled
by GUC and should thus be reloaded by the GUC routines already, but I'm
not sure there.

* Does pgstat, startup, shutdown, checkpointer and bgwriter need to have
the locale set as well, or can they live with defaults? (my fix only
fixes standard backends, since they have different exec paths)

* Locale can't be changed "on-the-fly", if I'm correct. So just setting
it upon exec should be enough. Or am I wrong there?

//Magnus


Attachment

Re: locale issues on win32 (fix?)

From
Tom Lane
Date:
"Magnus Hagander" <mha@sollentuna.net> writes:
> * Is it enough to explicitly store/save LC_COLLATE and LC_CTYPE, or does
> more of the locale stuff need to be stored?

The other LC_xxx settings will get fixed by GUC *only* if there are
explicit settings in postgresql.conf ... I don't think you can assume that.

> * Does pgstat, startup, shutdown, checkpointer and bgwriter need to have
> the locale set as well, or can they live with defaults?

You need to fix at least LC_MESSAGES, surely, if you want errors from
these processes suitably localized.  Although in theory none of these
guys do any index operations and so should not need LC_COLLATE set,
it scares me to think of what might go wrong; probably best to fix
'em all.

Note that I am about to whack around the checkpointer and bgwriter, so
you might want to wait a day or two before you try to do this.

> (my fix only
> fixes standard backends, since they have different exec paths)

If those guys do not go through that variable-saving-and-restoring
routine, they are probably broken ipso facto.  You sure they don't?

> * Locale can't be changed "on-the-fly", if I'm correct. So just setting
> it upon exec should be enough. Or am I wrong there?

Sounds sufficient to me.  All you are doing is implementing a substitute
for the Unix copy-on-fork behavior.

            regards, tom lane