Re: LogwrtResult contended spinlock - Mailing list pgsql-hackers

From Andres Freund
Subject Re: LogwrtResult contended spinlock
Date
Msg-id E494450B-9C6B-4716-9902-976DC7D69490@anarazel.de
Whole thread Raw
In response to Re: LogwrtResult contended spinlock  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: LogwrtResult contended spinlock  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Hi,

On August 31, 2020 11:34:45 AM PDT, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>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.

All relevant platforms have 64bit atomics. So I don't think there's much point in worrying about the emulated
performance.Correctness, sure. Performance, not so much. 

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: LogwrtResult contended spinlock
Next
From: Andres Freund
Date:
Subject: Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior