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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
