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
match
