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.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to