Обсуждение: 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

"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