Re: Reducing ClogControlLock contention - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Reducing ClogControlLock contention
Date
Msg-id CANP8+jJNXe=nooPPkPKfZMdTsD8Cq3CFc0YxQjtPzf+SU0VuTg@mail.gmail.com
Whole thread Raw
In response to Re: Reducing ClogControlLock contention  (Andres Freund <andres@anarazel.de>)
Responses Re: Reducing ClogControlLock contention  (Andres Freund <andres@anarazel.de>)
Re: Reducing ClogControlLock contention  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 1 July 2015 at 11:14, Andres Freund <andres@anarazel.de> wrote:
On 2015-07-01 09:08:11 +0100, Simon Riggs wrote:
> On 1 July 2015 at 09:00, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> > On Tue, Jun 30, 2015 at 12:32 PM, Simon Riggs <simon@2ndquadrant.com>
> > a.  the semantics of new LWLock (CommitLock) introduced
> > by patch seems to be different in the sense that it is just taken in
> > Exclusive mode (and no Shared mode is required) as per your proposal. We
> > could use existing LWLock APi's, but on the other hand we could even
> > invent new LWLock API for this kind of locking.
> >
>
> LWLock API code is already too complex, so -1 for more changes there

I don't think that's a valid argument. It's better to have the
complexity in one place (lwlock) than have rather similar complexity in
several other places. The clog control lock is far from the only place
that would benefit from tricks along these lines.

What "tricks" are being used??

Please explain why taking 2 locks is bad here, yet works fine elsewhere. 

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Reducing ClogControlLock contention
Next
From: Andres Freund
Date:
Subject: Re: Reducing ClogControlLock contention