RE: Hardwired MAXBACKENDS limit could be history

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема RE: Hardwired MAXBACKENDS limit could be history
Дата
Msg-id 8F4C99C66D04D4118F580090272A7A234D32C2@sectorbase1.sectorbase.com
обсуждение исходный текст
Ответ на Hardwired MAXBACKENDS limit could be history  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Hardwired MAXBACKENDS limit could be history  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Mikheev, Vadim"
Дата:
Сообщение: RE: Open 7.1 items
Следующее
От: Tom Lane
Дата:
Сообщение: Re: This script will crash the connection