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.
merlin