From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Дмитрий Дегтярёв <degtyaryov(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Cpu usage 100% on slave. s_lock problem. |
Date: | 2013-08-27 17:17:55 |
Message-ID: | CAHyXU0yLWU4O=0n6qm5tDTDxBdNwzjhUfA456cYggWY6zUXDMg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Aug 27, 2013 at 10:55 AM, Andres Freund <andres(at)2ndquadrant(dot)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
Attachment | Content-Type | Size |
---|---|---|
recovery3.patch | application/octet-stream | 3.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2013-08-27 21:27:25 | Re: SQL statement over 500% slower with 9.2 compared with 9.1 |
Previous Message | Andres Freund | 2013-08-27 15:55:56 | Re: Cpu usage 100% on slave. s_lock problem. |