Skip site navigation (1) Skip section navigation (2)

Re: Make check problem with 7.2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steven N=?ISO-8859-1?B?+vE=?=ez <nunez(at)itl-global(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Make check problem with 7.2
Date: 2002-03-04 02:15:20
Message-ID: 24237.1015208120@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Steven N=?ISO-8859-1?B?+vE=?=ez <nunez(at)itl-global(dot)com> 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

In response to

Responses

pgsql-bugs by date

Next:From: Steven N=?ISO-8859-1?B?+vE=?=ezDate: 2002-03-04 03:35:01
Subject: Re: Make check problem with 7.2
Previous:From: Steven N=?ISO-8859-1?B?+vE=?=ezDate: 2002-03-04 01:02:42
Subject: Re: Make check problem with 7.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group