On Tue, Apr 10, 2007 at 10:23:42AM -0400, Tom Lane wrote: > Mark Kirkwood <[EMAIL PROTECTED]> writes: > > Kris Kennaway wrote: > >> If so, then your task is the following: > >> > >> Make SYSV semaphores less dumb about process wakeups. Currently > >> whenever the semaphore state changes, all processes sleeping on the > >> semaphore are woken, even if we only have released enough resources > >> for one waiting process to claim. i.e. there is a thundering herd > >> wakeup situation which destroys performance at high loads. Fixing > >> this will involve replacing the wakeup() calls with appropriate > >> amounts of wakeup_one(). > > > I'm forwarding this to the pgsql-hackers list so that folks more > > qualified than I can comment, but as I understand the way postgres > > implements locking each process has it *own* semaphore it waits on - > > and who is waiting for what is controlled by an in (shared) memory hash > > of lock structs (access to these is controlled via platform Dependant > > spinlock code). So a given semaphore state change should only involve > > one process wakeup. > > Correct. The behavior Kris describes is surely bad, but it's not > relevant to Postgres' usage of SysV semaphores.
Sorry, but the behaviour is real. Kris
pgphJTqz6La4j.pgp
Description: PGP signature
