Thread: Re: [pgsql-hackers-win32] [HACKERS] select like...not using index
>> Here is what I think happened (this might be a bug, might not): Each >> night I run initdb but I use a special postgresql.conf which is >> optimized for quick data loading. This is copied over the >default one >> after the server is started. This contains the locale >information which >> is 'initialized by initdb'. These were still 'C' because >this file was >> generated before the default locale was changed. psql shows this >> information when you ask it for the locale info even if it is >> incorrect. > >I don't believe this for a minute. lc_ctype and lc_collate can *not* >be set from postgresql.conf. Try it. 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. //Magnus
Attachment
"Magnus Hagander" <mha@sollentuna.net> writes: > 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. regards, tom lane