Date: Mon, 31 Aug 2020 14:34:45 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org,
	Jaime Casanova <jaime.casanova@2ndQuadrant.com>
Subject: Re: LogwrtResult contended spinlock
Message-ID: <20200831183445.GA23447@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CE5FB7B4-BD5B-40C1-A915-0AE770812C3D@anarazel.de>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Aug-31, Andres Freund wrote:

> Hi, 
> 
> On August 31, 2020 11:21:56 AM PDT, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:

> >At first I wanted to make the new LWLock cover only LogwrtResult
> >proper,
> >and leave LogwrtRqst alone.  However on doing it, it seemed that that
> >might change the locking protocol in a nontrivial way.  So I decided to
> >make it cover both and call it a day.  We did verify that the patch
> >solves the reported problem, at any rate.
> 
> Wouldn't the better fix here be to allow reading of individual members
> without a lock? E.g. by wrapping each in a 64bit atomic.

Heh, Simon said the same.  It's not clear to me due to the lack of
general availability of 64-bit atomics.  If they are spinlock-protected
when emulated, I think that would make the problem worse.

IIRC Thomas wanted to start relying on atomic 64-bit vars in some patch,
but I don't remember what it was.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services