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 maximum number of semaphore sets
(SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be
exceeded. You need to raise the respective kernel parameter. Alternatively,
reduce PostgreSQL's consumption of semaphores by reducing its max_connections
parameter.
The PostgreSQL documentation contains more information about
configuring your system for 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
