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

From Mikheev, Vadim
Subject RE: Hardwired MAXBACKENDS limit could be history
Date
Msg-id 8F4C99C66D04D4118F580090272A7A234D32C2@sectorbase1.sectorbase.com
Whole thread Raw
In response to Hardwired MAXBACKENDS limit could be history  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Hardwired MAXBACKENDS limit could be history  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > 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?

Ops, you're right.

> > 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.

Conditional variables seem to be more portable - recently I had to
rewrite some program with POSIX sem developed under Solaris when
porting to AIX. (BTW, OmniORB uses cond vars to simulate semaphores).

Vadim


pgsql-hackers by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: RE: Open 7.1 items
Next
From: Tom Lane
Date:
Subject: Re: This script will crash the connection