ok, I've applied that patch and ran. The stall started around 13:50:45...50 and lasted until the end
the actual log has more data (including statement following each 'spin delay' record), but there is some sensitive info inside which I can't share with public.
-- Vlad
yup. this problem doesn't smell like lwlock issues. typically therethe problem manifests as low cpu performance, everybody waits.
classic spinlock contention (at least from what i've seen) is very
high *userspace* cpu utilization and low work output. this time it's
different -- OP is bogging in the kernel so it's not impossible we're
troubleshooting the symptom, not the cause.
yeah, OP should fire this off. good stuff. I'll bet lunch (if we ever
> In 9.3 there is a new field that tells how many spin delays there were
> on the mutex that is behind each lock. That was commit
> b79ab00144e64217d41, maybe he can port that back to his version.
>
> But that only tells you about LWLock mutexes, not about all the other
> ones in PG.
>
> The attached patch logs every spin delay with where in the source it comes from.
happen to meet) it's on buffer pin.
merlin
