Re: [HACKERS] Backends waiting, spinlocks, shared mem patches

Wayne Piekarski <wayne(at)senet(dot)com(dot)au> writes:
> Sorry this has taken me so long to get back to you.

Thanks for reporting back, Wayne.

> One thing we did notice is that when we tried to open more than say 50
> backends, we would get the following:
> InitPostgres
> IpcSemaphoreCreate: semget failed (No space left on device) key=5432017,
> num=16, permission=600
> proc_exit(3) [#0]
> Shortly after, we would get:
> FATAL: s_lock(18001065) at spin.c:125, stuck spinlock. Aborting.

Yes, 6.4.* does not cope gracefully at all with running out of kernel
semaphores. This is "fixed" in 6.5 by the brute-force approach of
grabbing all the semaphores we could want at postmaster startup, rather
than trying to allocate them on-the-fly during backend startup. Either
way, you want your kernel to be able to provide one semaphore per
potential backend.

> We tried the same massive number of connections test with 6.5 and it
> refuses to accept the connection after a while, which is good. I'm reading
> through archives about MaxBackendId now, so I'm going to play with that.

In 6.5 you just need to set the postmaster's -N switch.

> We have also been doing some testing with the latest 6.5 from the other
> day, to check that certain problems we've bumped into have been fixed. We
> can't run it live, but we'll try to run our testing programs on it as a
> best approximation to help flush out any bugs that might be left.

OK, please let us know ASAP if you spot problems... we are shooting for
formal 6.5 release one week from today...

regards, tom lane