Обсуждение: Error on system startup

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

"Matthew M.Burke" <mmburke@smcm.edu> writes:

> 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.

On Jan 13, 2004, at 2:28 PM, Manuel Sugawara wrote:

> "Matthew M.Burke" <mmburke@smcm.edu> writes:
>
>> 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

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

Chris Gamache <cgg007@yahoo.com> writes:
> 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