Simon Riggs <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings