cuckoo is hung during regression test

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема cuckoo is hung during regression test
Дата
Msg-id 20070213172445.GL64372@nasby.net
обсуждение исходный текст
Ответы Re: cuckoo is hung during regression test
Список 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
descriptor2023 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
postgresRET   sigprocmask 0 2023 postgres CALL  accept(0x7,0x200148c,0x200150c) 2023 postgres RET   accept -1 errno 24
Toomany open files 2023 postgres CALL  write(0x2,0x2003928,0x3b) 2023 postgres GIO   fd 2 wrote 59 bytes      "LOG:
couldnot 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)
2023postgres RET   select 1 2023 postgres CALL  sigprocmask(0x3,0x2f0d38,0) 2023 postgres RET   sigprocmask 0 2023
postgresCALL  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
manyopen 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@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: mark@mark.mielke.cc
Дата:
Сообщение: Re: Variable length varlena headers redux
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Variable length varlena headers redux