From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Re: Reducing sema usage (was Postmaster dies with many child processes) |
Date: | 1999-01-31 18:00:23 |
Message-ID: | 7873.917805623@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
>> A further thought: we could leave the semaphore management as-is,
>> and instead try to make running out of semaphores a less catastrophic
>> failure.
> If they asked for 64 backends, we better be able go give them to them,
> and not crash or fail under a load. 64 semaphores is nothing.
That argument would be pretty convincing if pre-grabbing the semaphores
was sufficient to ensure we could start N backends, but of course it's
not sufficient. The system could also run out of processes or file
descriptors, and I doubt that it's reasonable to grab all of those
instantly at postmaster startup.
The consensus seems clear not to go for the complex solution I described
at first. But I'm still vacillating whether to do pre-reservation of
semaphores or just fix the postmaster to reject a connection cleanly if
no more can be gotten. An advantage of the latter is that it would more
readily support on-the-fly changes of the max backend limit. (Which I
am *not* proposing to support now; I only plan to make it settable at
postmaster startup; but someday we might want to change it on the fly.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-01-31 18:38:19 | Re: [HACKERS] Patches |
Previous Message | Tom Lane | 1999-01-31 17:40:59 | Re: [HACKERS] Patches |