"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> The postmaster is stuck in the following loop, according to
> ktrace/kdump:
> 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
Interesting. So accept() fails because it can't allocate an FD, which
means that the select condition isn't cleared, so we keep retrying
forever. I don't see what else we could do though. Having the
postmaster abort on what might well be a transient condition doesn't
sound like a hot idea. We could possibly sleep() a bit before retrying,
just to not suck 100% CPU, but that doesn't really *fix* anything ...
I've been meaning to bug you about increasing cuckoo's FD limit anyway;
it keeps failing in the regression tests.
> 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?)
On my OS X machine, "ulimit -n unlimited" seems to set the limit to
10240 (or so a subsequent ulimit -a reports). But you could probably
fix it using the buildfarm parameter that cuts the number of concurrent
regression test runs.
regards, tom lane
---------------------------(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
