I wrote:
> A possible fix for this is to reorder the operations in FlushBuffer
> so that we share-lock the buffer before releasing BufMgrLock ... but
> I'm not sure that doesn't introduce other deadlock risks.
That's too simplistic, since at least one caller of FlushBuffer is
trying to write pages that may be in active use. If the target page
is already exclusive-locked by another process then a deadlock between
the per-buffer lock and BufMgrLock is entirely possible.
I think that it would work for BufferAlloc to share-lock the victim
buffer before calling FlushBuffer; we'd have to add a bool parameter to
FlushBuffer telling it the lock was already acquired. This is safe in
this particular path because a buffer that was just taken from the
freelist should not be exclusive-locked by anyone. (It could possibly
be share-locked by the bgwriter, but that won't cause a deadlock.)
A process that wanted exclusive lock would first have to pin the buffer,
which can't happen before we release the BufMgrLock. By adding the
parameter we'd avoid changing the behavior for other callers.
Comments, better ideas?
BTW, it looks to me like this deadlock potential has existed at least
since 7.0. I seem to recall one or two reports of unexplainable
apparent deadlocks, which perhaps are now explained.
regards, tom lane
