Re: Reducing sema usage (was Postmaster dies with many child processes)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Reducing sema usage (was Postmaster dies with many child processes)
Date: 1999-01-31 00:42:25
Message-ID: 5837.917743345@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Cary O'Brien 1999-01-31 01:09:45 Backends and semaphores
Previous Message Tom Lane 1999-01-31 00:11:54 Reducing sema usage (was Postmaster dies with many child processes)