Re: [PERFORM] Cpu usage 100% on slave. s_lock problem.
От | Merlin Moncure |
---|---|
Тема | Re: [PERFORM] Cpu usage 100% on slave. s_lock problem. |
Дата | |
Msg-id | CAHyXU0yRAzJC0zimZGH2F=VtM7yDGJZHC9rE3dcRFAF=kSETrw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PERFORM] Cpu usage 100% on slave. s_lock problem. (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [PERFORM] Cpu usage 100% on slave. s_lock problem.
Re: [PERFORM] Cpu usage 100% on slave. s_lock problem. |
Список | pgsql-hackers |
On Mon, Sep 30, 2013 at 8:15 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > On 9/27/13 3:00 PM, Merlin Moncure wrote: >> Attached is simplified patch that replaces the spinlock with a read >> barrier based on a suggestion made by Andres offlist. > > This patch doesn't apply. works for me: merlin@mmoncure-ubuntu:~/pgdev/pgsql$ git reset --hard HEAD HEAD is now at 200ba16 Add regression test for bug fixed by recent refactoring. merlin@mmoncure-ubuntu:~/pgdev/pgsql$ patch -p1 < buffer5.patch patching file src/backend/access/transam/xlog.c On Mon, Sep 30, 2013 at 7:51 PM, Ants Aasma <ants@cybertec.at> wrote: > So we need a read barrier somewhere *after* reading the flag in > RecoveryInProgress() and reading the shared memory structures, and in > theory a full barrier if we are going to be writing data. wow -- thanks for your review and provided detail. Considering there are no examples of barrier instructions to date, I think some of your commentary should be included in the in-source documentation. In this particular case, a read barrier should be sufficient? By 'writing data', do you mean to the xlog control structure? This routine only sets a backend local flag so that should be safe? merlin
В списке pgsql-hackers по дате отправления: