Error on system startup

[Matthew M.Burke]

I am using postgresql 7.4.0 on Debian 3.0r2 (Woody) on an x86 box. I'm
using the binary package from http://people.debian.org/~elphick/debian/

If I run the initscript from the command line:

invoke-rc.d postgresql start

it starts up just fine. But when I reboot the system, it fails to
start and I get the following in the log:

FATAL: XX000: failed to initialize lc_messages to ""
LOCATION: InitializeGUCOptions, guc.c:1866


As soon as I have more than two minutes to spare, I'll write up and
post a bug report to the appropriate list, but I have a hunch that the
problem is a configuration issue---missing environment variable---and
was hoping someone might have some suggestions for a quick fix.

Thanks,

Matt






---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ***@postgresql.org)

[Manuel Sugawara]

Post by Matthew M.Burke
FATAL: XX000: failed to initialize lc_messages to ""
LOCATION: InitializeGUCOptions, guc.c:1866

Edit your $PGDATA/postgresql.conf file and look for that variable
(lc_messages) and change the empty value with a correct one (may be
en_US). Same for the others lc_* variables.

Regards,
Manuel.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ***@postgresql.org

[Matthew M.Burke]

Post by Manuel Sugawara

Post by Matthew M.Burke
FATAL: XX000: failed to initialize lc_messages to ""
LOCATION: InitializeGUCOptions, guc.c:1866

Edit your $PGDATA/postgresql.conf file and look for that variable
(lc_messages) and change the empty value with a correct one (may be
en_US). Same for the others lc_* variables.

Manuel,

Thanks for the help. I found the variables commented out in
$PGDATA/postgresql.conf and uncommented them. Didn't help. Wound up
sticking

export LC_MESSAGES='POSIX'

in the initscript and that seems to be doing the trick.

Matt



---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Chris Gamache]

I have one RAID 1+0 array available. My primary concern is data integrity.

The general instruction is to put pg_xlog on another filesystem, seperated
physically from the database files, for maximum performance. That is what I had
planned on doing. However, it dawned on me that there could be a serious
problem if the pg_xlog got corrupted or was lost in a hardware failure. It
might not matter one bit that the actual data files are safe and sound if the
transaction log is corrupted.

Is protecting pg_xlog as important as protecting the rest of the data files?

Will the performance hit, which happens when one keeps pg_xlog on the same
filesystem as the database, be substantial enough to warrant spending more
money on another array of drives to use for pg_xlog?

CG

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Tom Lane]

It might not matter one bit that the actual data files are safe and
sound if the transaction log is corrupted.

There's always pg_resetxlog.

However, if you value data integrity over performance, it'd probably be
better to have data+log on one redundant array than to have data on a
redundant array and log on a single nonredundant disk.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend