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

On Mon, Sep 30, 2013 at 8:15 AM, Peter Eisentraut <peter_e(at)gmx(dot)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(at)mmoncure-ubuntu:~/pgdev/pgsql$ git reset --hard HEAD
HEAD is now at 200ba16 Add regression test for bug fixed by recent refactoring.
merlin(at)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(at)cybertec(dot)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