On Sat, 2005-01-01 at 18:55, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I think the proposal sounds safe, though I worry about performance.
>
> There is no performance loss; we are just changing the order in which
> we acquire two locks. If there were some risk of blocking for a
> measurable time while holding the BufMgrLock, then that would be bad for
> concurrent performance --- but in fact the per-buffer lock is guaranteed
> free at that point.
>
> I don't think there's any value in trying to avoid the I/O. This is a
> corner case of such rarity that it's only been seen perhaps half a dozen
> times in the history of the project. "Optimizing" it is not the proper
> concern. The case where the I/O is wasted because someone re-pins the
> buffer during the write is far more likely, simply because of the
> relative widths of the windows involved; and we can't avoid that.
The deadlock is incredibly rare, I agree. That was not my point.
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.
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.
> Bottom line is that I don't think it's useful to consider this as a
> performance issue. What we need is correctness with minimum extra
> complication of the logic.
I'll step aside and look more closely for 8.1
--
Best Regards, Simon Riggs
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
