]> granicus.if.org Git - postgresql/commit
Change locking regimen around buffer replacement.
authorRobert Haas <rhaas@postgresql.org>
Thu, 25 Sep 2014 14:43:24 +0000 (10:43 -0400)
committerRobert Haas <rhaas@postgresql.org>
Thu, 25 Sep 2014 14:43:24 +0000 (10:43 -0400)
commit5d7962c6797c0baae9ffb3b5b9ac0aec7b598bc3
tree9abf4b7ad28b57c77305b5b1361d3468642bc299
parent1dcfb8da09c47d2a7502d1dfab06c8be4b6cf323
Change locking regimen around buffer replacement.

Previously, we used an lwlock that was held from the time we began
seeking a candidate buffer until the time when we found and pinned
one, which is disastrous for concurrency.  Instead, use a spinlock
which is held just long enough to pop the freelist or advance the
clock sweep hand, and then released.  If we need to advance the clock
sweep further, we reacquire the spinlock once per buffer.

This represents a significant increase in atomic operations around
buffer eviction, but it still wins on many workloads.  On others, it
may result in no gain, or even cause a regression, unless the number
of buffer mapping locks is also increased.  However, that seems like
material for a separate commit.  We may also need to consider other
methods of mitigating contention on this spinlock, such as splitting
it into multiple locks or jumping the clock sweep hand more than one
buffer at a time, but those, too, seem like separate improvements.

Patch by me, inspired by a much larger patch from Amit Kapila.
Reviewed by Andres Freund.
src/backend/storage/buffer/README
src/backend/storage/buffer/bufmgr.c
src/backend/storage/buffer/freelist.c
src/include/storage/buf_internals.h
src/include/storage/lwlock.h