OK, that's one LOCALE bug report too many...

... and I am not going to allow 7.1 to go out without a fix for this
class of problems. I'm fed up ;-)

As near as I can tell from the setlocale() man page, the only locale
categories that are really hazardous for us are LC_COLLATE and LC_CTYPE;
the other categories like LC_MONETARY affect only I/O routines, not
sort ordering, and so cannot result in corrupt indices.

I propose, therefore, that in an --enable-locale installation, initdb
should save its values for LC_COLLATE and LC_CTYPE in pg_control, and
backend startup should restore these settings from pg_control. Other
locale categories will continue to be acquired from the postmaster
environment. This will eliminate the class of bugs associated with
index corruption from not always starting the postmaster with the same
locale settings, while not forcing people to do an initdb to change
harmless settings.

Also, since "LC_COLLATE=en_US" seems to misbehave rather spectacularly
on recent RedHat releases, I propose that initdb change "en_US" to "C"
if it finds that setting. (Are there any platforms where there are
non-bogus differences between the two?)

Finally, until we have a really bulletproof solution for LIKE indexing
optimization, I will disable that optimization if --enable-locale is
compiled *and* LC_COLLATE is not C. Better to get "LIKE is slow" bug
reports than "LIKE gives wrong answers" bug reports.

Comments? Anyone think that initdb should lock down more categories
than just these two?

regards, tom lane