On Tue, Aug 27, 2013 at 8:38 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Tue, Aug 27, 2013 at 8:23 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
>> It looks like you're hitting spinlock connection inside
>> heap_page_prune_opt(). Which is commented:
>> * Note: this is called quite often. It's important that it fall out quickly
>> * if there's not any use in pruning.
>>
>> This in turn calls RecoveryInProgress() which spinlocks in order to
>> get a guaranteed result. At that call site, we are told:
>> /*
>> * We can't write WAL in recovery mode, so there's no point trying to
>> * clean the page. The master will likely issue a cleaning WAL record soon
>> * anyway, so this is no particular loss.
>> */
>>
>> So ISTM it's necessary to pedantically check RecoveryInProgress on
>> each and every call of this routine (or at least, we should be able to
>> reduce the number of spinlocks).
>>
>> Hm, what if we exposed LocalRecoveryInProgress() through a function
>> which would approximately satisfy the condition
>> "MightRecoveryInProgress()" in the basis the condition only moves in
>> one direction? That could lead to optimization around the spinlock in
>> hot path cases like this where getting 'TRUE' incorrectly is mostly
>> harmless...
>
> More specifically, this hypothetical routine would query
> xlogctl->SharedRecoveryInProgress without taking a lock and would not
> issue InitXLOGAccess(). RecoveryInProgress() seems to be called
> everywhere (In particular: StartTransaction()) so I don't think
> there's a lot of risk in terms of losing access to the xlog.
Something like the attached. Note, this patch is for research
purposes only and should *not* be applied to your production
environment.
merlin