Re: [PERFORM] Cpu usage 100% on slave. s_lock problem.
От | Andres Freund |
---|---|
Тема | Re: [PERFORM] Cpu usage 100% on slave. s_lock problem. |
Дата | |
Msg-id | 20130927215359.GD9819@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: [PERFORM] Cpu usage 100% on slave. s_lock problem. (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [PERFORM] Cpu usage 100% on slave. s_lock problem.
|
Список | 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
В списке pgsql-hackers по дате отправления: