RE: Hardwired MAXBACKENDS limit could be history

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: RE: Hardwired MAXBACKENDS limit could be history
Date: 2001-01-26 18:24:12
Message-ID: 8F4C99C66D04D4118F580090272A7A234D32C2@sectorbase1.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Felix König 2001-01-26 18:27:24 Trouble porting postgreSQL to WinNT
Previous Message Mikheev, Vadim 2001-01-26 18:02:59 RE: Open 7.1 items