| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steven N=?ISO-8859-1?B?+vE=?=ez | 2002-03-04 03:35:01 | Re: Make check problem with 7.2 |
| Previous Message | Steven N=?ISO-8859-1?B?+vE=?=ez | 2002-03-04 01:02:42 | Re: Make check problem with 7.2 |