"Eric B. Ridge" writes:
> On Dec 10, 2009, at 6:58 PM, Tom Lane wrote:
>> It seems likely that the root cause is having somehow lost a wakeup signal
>> somewhere
> What would cause that?
Who knows? It could be a kernel bug or a hardware glitch. If it were a
Postgres bug I think we'd have seen
On Dec 10, 2009, at 6:58 PM, Tom Lane wrote:
> It seems likely that the root cause is having somehow lost a wakeup signal
> somewhere
What would cause that?
eric
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
"Eric B. Ridge" writes:
> On Dec 10, 2009, at 6:28 PM, Tom Lane wrote:
>> It looks like somehow the SInvalLock got stuck --- that would account
>> for both the stack traces you show.
> What's a SInvalLock? I looked at the code/comments for
> ReceiveSharedInvalidMessages(), but it didn't make
On Dec 10, 2009, at 6:28 PM, Tom Lane wrote:
> It looks like somehow the SInvalLock got stuck --- that would account
> for both the stack traces you show.
What's a SInvalLock? I looked at the code/comments for
ReceiveSharedInvalidMessages(), but it didn't make much sense out of context.
> I'
"Eric B. Ridge" writes:
> Postgres locked up. All existing backends (roughly 100) couldn't execute
> commands. They'd just hang. One random backend I selected had this
> backtrace:
> (gdb) bt
> #0 0xb7f7f410 in __kernel_vsyscall ()
> #1 0xb7e37a6b in semop () from /lib/libc.so.6
> #2 0x08
# select version():
PostgreSQL 8.1.10 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.2
(Gentoo 4.1.2 p1.0.1)
(I know, I know, it's an old version of PG whose sources aren't even available
today. Nonetheless, we've had great success with it.)
# uname -a
Linux servername 2.6.24.3-TCDI #16 S
