From: | "Laura Hornbeck" <lhornbeck(at)oppunl(dot)com> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: FATAL: the database system is in recovery mode |
Date: | 2006-10-12 18:22:31 |
Message-ID: | 20061012182155.B5F3F9FA0FE@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
-----Original Message-----
From: pgsql-novice-owner(at)postgresql(dot)org
[mailto:pgsql-novice-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
Sent: Thursday, October 12, 2006 1:10 PM
To: lhornbeck(at)oppunl(dot)com
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: [NOVICE] FATAL: the database system is in recovery mode
"Laura Hornbeck" <lhornbeck(at)oppunl(dot)com> writes:
> Hmmm ... unless you had extremely high settings for both
> checkpoint_segments and checkpoint_timeout, it shouldn't take an hour to
recover from a crash.
> checkpoint_segments is 8.
That's certainly not out of line --- I'd expect a max recovery time on the
order of a minute or so for that much WAL.
> strace -p26891
> Process 26891 attached - interrupt to quit futex(0xb7db2880,
> FUTEX_WAIT, 2, NULL
Interesting. We don't use futexes directly, so this smells like a problem
in glibc or some such. Can you get a stack trace?
$ gdb /path/to/postgres-executable 26891
gdb> bt
gdb> quit
regards, tom lane
#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 ?? ()
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-12 18:32:02 | Re: FATAL: the database system is in recovery mode |
Previous Message | Tom Lane | 2006-10-12 18:09:48 | Re: FATAL: the database system is in recovery mode |