| От | Tom Lane |
|---|---|
| Тема | Re: Hardwired MAXBACKENDS limit could be history |
| Дата | |
| Msg-id | 2596.980531262@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | RE: Hardwired MAXBACKENDS limit could be history ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
| Список | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера