Re: Hardwired MAXBACKENDS limit could be history - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hardwired MAXBACKENDS limit could be history
Date
Msg-id 2596.980531262@sss.pgh.pa.us
Whole thread Raw
In response to RE: Hardwired MAXBACKENDS limit could be history  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: RE: Hardwired MAXBACKENDS limit could be history
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: Open 7.1 items