> I'm not thinking about getting this done in time for 7.1, but I think
> it'd be a nice cleanup for 7.2.
> 
> Bruce, a TODO item please:
>   * Remove compile-time upper limit on number of backends 
> (MAXBACKENDS)

Did you ever consider remove per-backend semaphores at all?
We use them to sleep waiting for lock (ie when someone awake
us by changing our semaphore) - why don't use sigpause and
some signal? Semaphores are good to sync access to *shared*
resources but it's not that case here.

Vadim

Fri, 26 Jan 2001 09:29:08 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Hardwired MAXBACKENDS limit could be history
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> Did you ever consider remove per-backend semaphores at all?
> We use them to sleep waiting for lock (ie when someone awake
> us by changing our semaphore) - why don't use sigpause and
> some signal?

That'll fail if the signal arrives before the sigpause(), no?

> Semaphores are good to sync access to *shared*
> resources but it's not that case here.

The thing we really need here is that the right thing has to happen
if the V() occurs before our P(), ie, the V() has to be remembered
so that we will fall through the P() without blocking.

What I'd like to look at sometime soon is using POSIX semaphores
instead of SysV semaphores.  But we need stateful semaphores,
not signals.

			regards, tom lane

Fri, 26 Jan 2001 12:47:42 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Hardwired MAXBACKENDS limit could be history 