Re: troubleshooting hung postmasters

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: troubleshooting hung postmasters
Date: 2005-12-05 18:44:41
Message-ID: 1355.1133808281@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Ed L." <pgsql(at)bluepolka(dot)net> writes:
> I need some troubleshooting help with two hung postmasters
> this morning, both PostgreSQL 7.4.6 on ia64-hp-hpux11.23,
> compiled by gcc 3.4.2, each on a separate rx4640.

> (gdb) bt
> #0 0xc000000000304230:0 in _accept_sys+0x30 () from /usr/lib/hpux64/libc.so.1
> #1 0xc0000000003100b0:0 in accept+0x150 () from /usr/lib/hpux64/libc.so.1
> #2 0xc000000001aac450:0 in accept+0x70 () from /usr/lib/hpux64/libxnet.so.1
> #3 0x400000000029a710:0 in StreamConnection+0x50 ()
> #4 0x40000000003147f0:0 in ServerLoop+0x4e0 ()
> #5 0x4000000000318cd0:0 in PostmasterMain+0x1080 ()
> #6 0x400000000029e470:0 in main+0x490 ()

Hmm, this appears to indicate that the postmaster is stuck on an
accept() on a socket that was reported read-ready by select()
(else control would not reach StreamConnection), yet the socket
doesn't actually have an available connection (else it wouldn't block).

I'm not sure how this condition can occur --- you might want to ask
some HPUX gurus about it. It looks like a kernel bug to me; I can't
see anything in the man pages suggesting that select's read-ready
indication might be a lie.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Eric E 2005-12-05 19:02:27 Preventing or controlling runaway queries
Previous Message Tom Lane 2005-12-05 18:31:20 Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits