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.


Attachment: pgphJTqz6La4j.pgp
Description: PGP signature

Reply via email to