On Fri, Nov 18, 2011 at 10:29 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> So the upside and downside of this approach is that it modifies the
> existing LWLock implementation rather than allowing multiple lock
> implementations to exist side-by-side. That means every LWLock in the
> system has access to this functionality, which might be convenient if
> there turn out to be many uses for this technique.
Right.
> The bad news is
> that everyone pays the cost of checking the work queue in
> LWLockRelease().
I hope that would be minimal (may be just one instruction) for those
who don't want to use the facility.
> It also means that you can't, for example, create a
> custom lock with different lock modes (e.g. S, SX, X, as I proposed
> upthread).
>
Thats a valid point.
> I am pretty dubious that there are going to be very many cases where
> we can get away with holding the spinlock while doing the work. For
> example, WAL flush is a clear example of where we can optimize away
> spinlock acquisitions - if we communicate to people we wake up that
> their LSN is already flushed, they needn't reacquire the lock to
> check. But we certainly can't hold a spinlock across a WAL flush.
>
I think thats mostly solvable as said upthread. We can and should
improve this mechanism so that the work is carried out with the
necessary LWLock instead of the spinlock. That would let other
processes to queue up for the lock while the tasks are being executed.
Or if the tasks only need shared lock, then other normal shared
requesters can go ahead and acquire the lock.
When I get some time, I would like to see if this can be extended to
have shared snapshots so that multiple callers of GetSnapshotData()
get the same snapshot, computed only once by scanning the proc array,
instead of having each process compute its own snapshot which remains
the same unless some transaction ends in between.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com