Re: Cpu usage 100% on slave. s_lock problem.

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Cpu usage 100% on slave. s_lock problem.
Дата
Msg-id CAHyXU0yLWU4O=0n6qm5tDTDxBdNwzjhUfA456cYggWY6zUXDMg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Cpu usage 100% on slave. s_lock problem.  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Cpu usage 100% on slave. s_lock problem.
Re: Cpu usage 100% on slave. s_lock problem.
Список pgsql-performance
On Tue, Aug 27, 2013 at 10:55 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-08-27 09:57:38 -0500, Merlin Moncure wrote:
>> + bool
>> + RecoveryMightBeInProgress(void)
>> + {
>> +     /*
>> +      * We check shared state each time only until we leave recovery mode. We
>> +      * can't re-enter recovery, so there's no need to keep checking after the
>> +      * shared variable has once been seen false.
>> +      */
>> +     if (!LocalRecoveryInProgress)
>> +             return false;
>> +     else
>> +     {
>> +             /* use volatile pointer to prevent code rearrangement */
>> +             volatile XLogCtlData *xlogctl = XLogCtl;
>> +
>> +             /* Intentionally query xlogctl without spinlocking! */
>> +             LocalRecoveryInProgress = xlogctl->SharedRecoveryInProgress;
>> +
>> +             return LocalRecoveryInProgress;
>> +     }
>> + }
>
> I don't think it's acceptable to *set* LocalRecoveryInProgress
> here. That should only be done in the normal routine.

quite right -- that was a major error -- you could bypass the
initialization call to the xlog with some bad luck.

merlin

Вложения

В списке pgsql-performance по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Cpu usage 100% on slave. s_lock problem.
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: SQL statement over 500% slower with 9.2 compared with 9.1