>> It certainly doesn't. There still was a bug with the locale stuff, >> though - the GUC variable was not set in the child >processes. So "show >> lc_collate" would *always* return "C", for example. attached >patch fixes >> this. > >Hm. Why were these vars not propagated by the regular >mechanism for GUC >variables (write_nondefault_variables or whatever it's called)? If the >problem is that it's not accepting PGC_INTERNAL values, then we need to >fix it there not here, because otherwise we'll have to pass all the >PGC_INTERNAL variables through the backend_variables file, which seems >like a recipe for more of the same sort of bug.
Good point :-( I think the problem is not only that it specifically does not deal with PGC_INTERNAL variables. The problem is in the fact that write_nondefault_variables is called *before* the locale is read (because the locale is read from pg_control and not from any of the "usual" ways to read it). Attached patch is another stab at fixing it. It makes postmaster dump a new copy of the file once it has started the database (before it accepts any connections), which is when it will know about these parameters. Also updates the reading code to set the context to the one where the variable was originally set (PGC_POSTMASTER won't work for PGC_INTERNAL, and the other way around). We still pass lc_collate through the special file, because set_config_option on lc_collate will speficially *not* call setlocale(), and we need that call. But we no longer call set_config_option from there. //Magnus
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly