Re: LogwrtResult contended spinlock

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>
Subject: Re: LogwrtResult contended spinlock
Date: 2020-09-04 17:05:45
Message-ID: 20200904170545.ko4bwixl3yuu5jxz@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-09-03 14:34:52 -0400, Alvaro Herrera wrote:
> Looking at patterns like this
>
> if (XLogCtl->LogwrtRqst.Write < EndPos)
> XLogCtl->LogwrtRqst.Write = EndPos;
>
> It seems possible to implement with
>
> do {
> XLogRecPtr currwrite;
>
> currwrite = pg_atomic_read_u64(LogwrtRqst.Write);
> if (currwrite > EndPos)
> break; // already done by somebody else
> if (pg_atomic_compare_exchange_u64(LogwrtRqst.Write,
> currwrite, EndPos))
> break; // successfully updated
> } while (true);
>
> This assumes that LogwrtRqst.Write never goes backwards, so it doesn't
> seem good material for a general routine.
>
> This *seems* correct to me, though this is muddy territory to me. Also,
> are there better ways to go about this?

Hm, I was thinking that we'd first go for reading it without a spinlock,
but continuing to write it as we currently do.

But yea, I can't see an issue with what you propose here. I personally
find do {} while () weird and avoid it when not explicitly useful, but
that's extremely minor, obviously.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-09-04 17:13:55 Re: LogwrtResult contended spinlock
Previous Message Ranier Vilela 2020-09-04 16:55:52 Re: [PATCH] Redudant initilization