Re: [PERFORM] Cpu usage 100% on slave. s_lock problem.

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Дмитрий Дегтярёв <degtyaryov(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PERFORM] Cpu usage 100% on slave. s_lock problem.
Date: 2013-09-27 21:53:59
Message-ID: 20130927215359.GD9819@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

What confuses me is that pg_read_barrier() is just a compiler barrier on
x86[-64] in barrier.h. According to my knowledge it needs to be an
lfence or the full barrier?
The linked papers from Paul McKenney - which are a great read - seem to
agree?

On 2013-09-27 23:12:17 +0200, Andres Freund wrote:
> On 2013-09-27 23:28:37 +0300, Heikki Linnakangas wrote:
> > The function RecoveryInProgress() function does just one load, to read the
> > variable, and wouldn't even need a barrier by itself. The other load or
> > store that needs to be protected by the barrier happens in the caller,
> > before or after the function, and we can't say for sure if it's a load or a
> > store. So, let's use pg_memory_barrier().
>
> The caller uses a spinlock, so it's guaranteed to write out before the
> spinlock is released. A write barrier (the spinlock in the startup
> process) should always be paired by a read barrier.

s/caller/startup process/

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Browne 2013-09-27 22:17:56 Re: Extra functionality to createuser
Previous Message Andres Freund 2013-09-27 21:39:47 Re: Wait free LW_SHARED acquisition