Re: Reducing sema usage (was Postmaster dies with many child processes) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reducing sema usage (was Postmaster dies with many child processes)
Date
Msg-id 5837.917743345@sss.pgh.pa.us
Whole thread Raw
In response to Reducing sema usage (was Postmaster dies with many child processes)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Re: Reducing sema usage (was Postmaster dies with many child processes)
List pgsql-hackers
I said:
> Any thoughts about which way to jump?  I'm sort of inclined to take
> the simpler approach myself...

A further thought: we could leave the semaphore management as-is,
and instead try to make running out of semaphores a less catastrophic
failure.  I'm thinking that the postmaster could be the one to try
to allocate more semaphores whenever there are none left, just before
trying to fork a new backend.  (The postmaster has access to the same
shared memory as the backends, right?  So no reason it couldn't do this.)
If the allocation fails, it can simply refuse the connection request,
rather than having to proceed as though we'd had a full-fledged backend
crash.  This only works because we can predict the number of semas
needed by an additional backend -- but we can: one.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Reducing sema usage (was Postmaster dies with many child processes)
Next
From: "Cary O'Brien"
Date:
Subject: Backends and semaphores