On Tue, Aug 11, 2015 at 7:32 PM, Simon Riggs <
simon@2ndquadrant.com> wrote:
>
> On 11 August 2015 at 11:39, Amit Kapila <
amit.kapila16@gmail.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.
