Simon Riggs <simon@2ndquadrant.com> writes:
> The situation where another backend requests the block immediately
> before the I/O is fairly common AFAICS, especially since
> StrategyGetBuffer ignores the BM_DIRTY flag in selecting victims.
How do you figure that? StrategyGetBuffer won't return the same buffer
again (because dirty or not, it'll be pinned by the time anyone else
gets to run StrategyGetBuffer). The case we are interested in is where
someone suddenly wants the original page again --- that is, a page that
was just about to fall off the back end of the freelist is wanted again.
I don't see that that case is common, especially not with a reasonably
large shared_buffer setting, and most especially not when the bgwriter
is doing its job and keeping the back end of the freelist clean.
> ISTM making the code deadlock-safe will effect cases where there never
> would have been a deadlock, slowing both backends down while waiting for
> the I/O to complete.
The other backend will have to wait for the I/O to complete before he
can gain an exclusive lock on the page ... but so what? If he'd come
along a microsecond later, he'd have had to wait, too. Basically we are
eliminating a very narrow window by causing it to behave the same as
what happens in the larger window where the I/O is occurring.
(BTW, "I/O" in this case actually just represents transferring the data
to kernel buffers, so the amount of delay involved is likely not to be
all that large...)
regards, tom lane
