I encountered a strange behavior of lightweight lock in PostgreSQL 9.2.  That 
appears to apply to 9.6, too, as far as I examine the code.  Could you tell me 
if the behavior is intended or needs fix?

Simply put, the unfair behavior is that waiters for exclusive mode are 
overtaken by share-mode lockers who arrive later.


Under a heavy read/write workload on a big machine with dozens of CPUs and 
hundreds of GBs of RAM, psql sometimes took more than 30 seconds to connect to 
the database (and actually, it failed to connect due to our connect_timeout 
setting.)  The backend corresponding to the psql was waiting to acquire 
exclusive mode lock on ProcArrayLock.  Some other backends took more than 10 
seconds to commit their transactions, waiting for exclusive mode lock on 

At that time, many backend processes (I forgot the number) were acquiring and 
releasing share mode lock on ProcArrayLock, most of which were from 


Going into the 9.2 code, I realized that those who request share mode don't pay 
attention to the wait queue.  That is, if some processes hold share mode lock 
and someone is waiting for exclusive mode in the wait queue, other processes 
who come later can get share mode overtaking those who are already waiting.  If 
many processes repeatedly request share mode, the waiters can't get exclusive 
mode for a long time.

Is this intentional, or should we make the later share-lockers if someone is in 
the wait queue?

Takayuki Tsunakawa

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to