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 [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match