locale issues on win32 (fix?)

Started by Magnus Haganderover 21 years ago2 messages
#1Magnus Hagander
mha@sollentuna.net
1 attachment(s)

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

Attachments:

locale_win32.patchapplication/octet-stream; name=locale_win32.patchDownload
*** postmaster.c.orig	Mon Apr 19 22:53:37 2004
--- postmaster.c	Mon Apr 19 22:58:45 2004
***************
*** 3305,3310 ****
--- 3305,3312 ----
  {
  	char	filename[MAXPGPATH];
  	FILE	*fp;
+ 	char    localebuf[64];
+ 
  	get_tmp_backend_file_name(filename,++tmpBackendFileNum);
  
  	/* Open file */
***************
*** 3359,3364 ****
--- 3361,3371 ----
  	write_var(debug_flag,fp);
  	write_var(PostmasterPid,fp);
  
+ 	strcpy(localebuf, setlocale(LC_COLLATE, NULL));
+ 	write_var(localebuf,fp);
+ 	strcpy(localebuf, setlocale(LC_CTYPE, NULL));
+ 	write_var(localebuf,fp);
+ 
  	/* Release file */
  	if (FreeFile(fp))
  	{
***************
*** 3376,3381 ****
--- 3383,3389 ----
  {
  	char	filename[MAXPGPATH];
  	FILE	*fp;
+ 	char    localebuf[64];
  	get_tmp_backend_file_name(filename,id);
  
  	/* Open file */
***************
*** 3420,3425 ****
--- 3428,3438 ----
  	read_var(PreAuthDelay,fp);
  	read_var(debug_flag,fp);
  	read_var(PostmasterPid,fp);
+ 
+ 	read_var(localebuf,fp);
+ 	setlocale(LC_COLLATE, localebuf);
+ 	read_var(localebuf,fp);
+ 	setlocale(LC_CTYPE, localebuf);
  
  	/* Release file */
  	FreeFile(fp);
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Magnus Hagander (#1)
Re: [HACKERS] locale issues on win32 (fix?)

"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