Re: Make check problem with 7.2

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Make check problem with 7.2
Дата
Msg-id
24237.1015208120@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Make check problem with 7.2 Steven Núñez <nunez@itl-global.com>
Re: Make check problem with 7.2 Tom Lane <tgl@sss.pgh.pa.us>
Re: Make check problem with 7.2 Steven Núñez <nunez@itl-global.com>
Re: Make check problem with 7.2 Steven Núñez <nunez@itl-global.com>
Re: Make check problem with 7.2 Tom Lane <tgl@sss.pgh.pa.us>
Re: Make check problem with 7.2 Steven Núñez <nunez@itl-global.com>
Re: Make check problem with 7.2 Bruce Momjian <pgman@candle.pha.pa.us>
Re: Make check problem with 7.2 Steven Núñez <nunez@itl-global.com>
Steven Núñez  writes:
> This time I've included the log file...

> DEBUG:  connection startup failed (fork failure): Resource temporarily
> unavailable
> DEBUG:  connection startup failed (fork failure): Resource temporarily
> unavailable
> DEBUG:  connection startup failed (fork failure): Resource temporarily
> unavailable
> DEBUG:  connection startup failed (fork failure): Resource temporarily
> unavailable
> DEBUG:  connection startup failed (fork failure): Resource temporarily
> unavailable
> DEBUG:  connection startup failed (fork failure): Resource temporarily
> unavailable

At a guess, you have the max-processes-per-user limit set too low.

The postmaster attempts to report the fork failure to the client,
but it looks like (at least on your platform) libpq gives up before
receiving the error message.  I wonder if it'd make sense for libpq
to ignore send failure on the startup packet, so it could move ahead
to receive the error message.  I have a feeling that would make the
behavior worse in other scenarios, though, so it may not be a win.
		regards, tom lane

В списке pgsql-bugs по дате отправления
От: Steven Núñez
Дата:
От: Steven Núñez
Дата:
FAQ