cuckoo is hung during regression test

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: cuckoo is hung during regression test
Date: 2007-02-13 17:24:45
Message-ID: 20070213172445.GL64372@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The 8.1 build for cuckoo is currently hung, with the *postmaster* taking
all the CPU it can get. The build started almost 5 hours ago.

The postmaster is stuck in the following loop, according to
ktrace/kdump:

2023 postgres RET write 59/0x3b
2023 postgres CALL close(0xffffffff)
2023 postgres RET close -1 errno 9 Bad file descriptor
2023 postgres CALL sigprocmask(0x3,0x2e6400,0)
2023 postgres RET sigprocmask 0
2023 postgres CALL select(0x8,0xbfffe194,0,0,0xbfffe16c)
2023 postgres RET select 1
2023 postgres CALL sigprocmask(0x3,0x2f0d38,0)
2023 postgres RET sigprocmask 0
2023 postgres CALL accept(0x7,0x200148c,0x200150c)
2023 postgres RET accept -1 errno 24 Too many open files
2023 postgres CALL write(0x2,0x2003928,0x3b)
2023 postgres GIO fd 2 wrote 59 bytes
"LOG: could not accept new connection: Too many open files
"
2023 postgres RET write 59/0x3b
2023 postgres CALL close(0xffffffff)
2023 postgres RET close -1 errno 9 Bad file descriptor
2023 postgres CALL sigprocmask(0x3,0x2e6400,0)
2023 postgres RET sigprocmask 0
2023 postgres CALL select(0x8,0xbfffe194,0,0,0xbfffe16c)
2023 postgres RET select 1
2023 postgres CALL sigprocmask(0x3,0x2f0d38,0)
2023 postgres RET sigprocmask 0
2023 postgres CALL accept(0x7,0x200148c,0x200150c)
2023 postgres RET accept -1 errno 24 Too many open files
2023 postgres CALL write(0x2,0x200381c,0x3b)
2023 postgres GIO fd 2 wrote 59 bytes
"LOG: could not accept new connection: Too many open files
"
2023 postgres RET write 59/0x3b

ulimit is set to 1224 open files, though I seem to keep bumping into that
(anyone know what the system-level limit is, or how to change it?)

Is there other useful info to be had about this process, or should I just kill
it?
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-02-13 17:39:39 pgsql: Add ORDER BY to vacummdb so databases are scaned in the same
Previous Message mark 2007-02-13 17:18:51 Re: Variable length varlena headers redux