I have killed it and it restarted fine. Thank you so much for your help.
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, October 12, 2006 1:32 PM
To: lhornbeck@oppunl.com
Cc: pgsql-novice@postgresql.org
Subject: Re: [NOVICE] FATAL: the database system is in recovery mode
"Laura Hornbeck" <lhornbeck@oppunl.com> writes:
>> Interesting. We don't use futexes directly, so this smells like a
>> problem in glibc or some such. Can you get a stack trace?
> #0 0xffffe410 in __kernel_vsyscall ()
> #1 0xb7d6031e in __lll_mutex_lock_wait () from /lib/tls/libc.so.6
> #2 0xb7cfe2b4 in _L_mutex_lock_2495 () from /lib/tls/libc.so.6
> #3 0xb7da2946 in __PRETTY_FUNCTION__.2189 () from /lib/tls/libc.so.6
> #4 0x00000000 in ?? ()
Hm, that's pretty unhelpful :-( ... I suppose you are using stripped
Postgres executables, so we're not going to be able to learn more here.
But it's definitely glibc getting wedged for some reason.
At this point I'd agree with kill -9'ing the subprocess, which will make its
parent postmaster quit, and then you can try again. It seems quite possible
that it won't lock up the next time. If it does lock up repeatably, perhaps
we could learn more with strace (try launching the postmaster under strace
-f). The last hundred or so lines of the strace output before it stops at
the futex call should give a hint what it's doing.
regards, tom lane
