Proposal: New LWLockmode LW_OWNER - Mailing list pgsql-hackers

Currently there are two modes of LWLock : SHARED and EXCLUSIVE
Mostly you need to have EXCLUSIVE lock mode to make any changes, add, 
delete and SHARED if you are just reading it.  Multiple backends can 
grab SHARED mode simultaneously while only one Backend can grab 
EXCLUSIVE at a time. There are situations when there are opportunities 
that certain values are typically changed by the same backend also in 
such cases when multiple backend  wants to change similarly values that 
they themselves typically change there is no lockmode which allows 
simultaneous updates in such cases and the result is sequential changes 
to the values which can be done simultaneously

New Lock Mode Proposed: LW_EX_OWNER  (input on better name will be 
appreciated).

So now there will be three modes SHARED, EXCLUSIVE, EX_OWNER
They will still be all mutually exclusive in the sense at any given time 
there can be only one mode active. However there is a marked difference 
while values of SHARED can be 0..N and EXCLUSIVE can be 0..1, the new 
lock mode EX_OWNER can be again 0..N.

This is primarily important so that we can carry out tasks of updates 
which not necessarily will be modified by any other backend.. Protection 
is guranteed since mostly old code will still have EXCLUSIVE lock so 
they will still need to work as guranteed. However advantage is for 
certain operations where we can still allow others to write into their 
own "area" with this EX_OWNER lock mode which allows multiple backend 
into shared area that they own. The area is not guaranteed by the lock 
mode but the procedure themselves and lock framework need not worry 
about that.

I wrote a prototype which needs changes in lwlock.h and lwlock.c and 
modifies lwlock.c which also awakes all SHARED together and if the first 
waiter is EX_OWNER it awakes all EX_OWNER together and if it EXCLUSIVE 
then just wakes the EXCLUSIVE waiter..


The potential for this new lock mode  can be used in various scenarios 
though it will need separate proposals on how to handle them since all 
bases are not covered yet but just as examples here:
1.  Proc array structure: Many times specific proc array structure is 
modified by the same backend.
2. WAL Buffers themselves: One way to make wal_buffer scalable is to 
have areas defined and have certain backend go against such areas rather 
than get the whole buffer lock. EXCLUSIVE is still used for most of them 
except certain identified parts..
3. Many other not identified yet.


Right now this proposal is only for the new Lock mode. Since thats a 
Lock framework enhancements which can give rise to multiple uses later

Regards,
Jignesh