On Tue, Aug 27, 2013 at 8:23 AM, Merlin Moncure <mmonc...@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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
