Could we replace SysV semaphores with latches?
От | Tom Lane |
---|---|
Тема | Could we replace SysV semaphores with latches? |
Дата | |
Msg-id | 3962.1339042176@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Could we replace SysV semaphores with latches?
Re: Could we replace SysV semaphores with latches? |
Список | pgsql-hackers |
There has been regular griping in this list about our dependence on SysV shared memory, but not so much about SysV semaphores, even though the latter cause their fair share of issues; as seen for example in buildfarm member spoonbill's recent string of failures: creating template1 database in /home/pgbuild/pgbuildfarm/HEAD/pgsql.25563/src/test/regress/./tmp_check/data/base/1 ... FATAL: could not create semaphores: No space left on device DETAIL: Failed system call was semget(1, 17, 03600). HINT: This error does *not* mean that you have run out of disk space. It occurs when either the system limit for the maximumnumber of semaphore sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exceeded. Youneed to raise the respective kernel parameter. Alternatively, reduce PostgreSQL's consumption of semaphores by reducingits max_connections parameter.The PostgreSQL documentation contains more information about configuring your systemfor PostgreSQL. child process exited with exit code 1 It strikes me that we have recently put together an independent but just about equivalent waiting mechanism in the form of latches. And not only that, but there's already a latch for each process. Could we replace our usages of SysV semaphores with WaitLatch on the procLatch? Unlike the situation with shared memory where we need some secondary features (mumble shm_nattch mumble), I think we aren't really using anything interesting about SysV semaphores except for the raw ability to wait for somebody to signal us. regards, tom lane
В списке pgsql-hackers по дате отправления: