On Tue, Aug 11, 2015 at 7:32 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > > On 11 August 2015 at 11:39, Amit Kapila <amit.kapil...@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. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
