Tom Lane wrote:
> "Jignesh K. Shah" <J.K.Shah@Sun.COM> writes:
>
>> New Lock Mode Proposed: LW_EX_OWNER (input on better name will be
>> appreciated).
>>
>
> This seems rather crazy, and you haven't actually given a single
> convincing use-case. Shouldn't you be trying to break down a lock
> into multiple locks instead of inventing new lock semantics that
> nobody really understands?
>
>
One area that I find it useful is where it will be useful is in
ProcArrayEndTransaction where it uses exclusive to update proc array
structure where right now it uses EXCLUSIVE and most commit transactions
are updating their own proc array structure this lock semantic can be
useful.. However I havent figured out on the last line where it updates
ShmemVariableCache->latestCompletedXid which might require still an
EXCLUSIVE lock and hence did not propose the use case.
http://doxygen.postgresql.org/procarray_8c-source.html#l00231
The whole concept of a single Exclusive lock to me is more flawed than
the proposed idea. Single Exclusive locks are artificial bottlenecks in
PostgreSQL and thats why a new lock semantic is helpful in opening
people's mind beyond exclusive lock and suddenly people will start doing
more parallel work where possible and LW_EX_OWNER allows that to work.
Which infact will allow somebody else to innovate on
ProcArrayEndTransaction and solve the problem that I could not figure
regarding latestCompletedXid.
In my sample test where putting LW_EX_OWNER or LW_OWNER as I have it my
code in ProcArrayEndTransaction the throughput of HEAD CVS went from
200,000 transactions per minute to 300,000 transactions per minute but
though in my case latestCompletedXid is unsafe. If thats solved, there
is a potential upswing in scalability in PostgreSQL core.
Once that function is implemented correctly, it will highlight other
places where such lock semantics could prove to be useful.. (My money on
WALInsertLock)
-Jignesh
