Re: Reducing ClogControlLock contention

On Tue, Aug 11, 2015 at 7:32 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On 11 August 2015 at 11:39, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
>>>>
>>>> Another thing is that in this flow, with patch there will be three
locks
>>>> (we take per-buffer locks before doing I/O) that will get involved
rather than
>>>> two, so one effect of this patch will be that currently while doing
I/O,
>>>> concurrent committers will be allowed to proceed as we release
ControlLock
>>>> before doing the same whereas with Patch, they will not be allowed as
they
>>>> are blocked by CommitLock. Now may be this scenario is less common and
>>>> doesn't matter much if the patch improves the more common scenario,
>>>> however this is an indication of what Andres tries to highlight that
having more
>>>> locks for this might make patch more complicated.
>>>
>>>
>>> It's easy to stripe the CommitLock in that case, if it is a problem.
>>
>>
>> Sure, I think other places in code that take both the other locks also
>> needs to be checked for updation.
>
>
> Not sure what that means, but there are no other places calling
CommitLock
>

What I mean is that if want to ensure that we don't keep CommitLock while
doing I/O, then we might also want to ensure the same while waiting for I/O.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com