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. > My suggestion: LockBuffer in FlushBuffer should return as unsuccessful > if there is an LW_EXCLUSIVE lock already held, causing another iteration > of the do while loop in BufferAlloc. This would break the other callers of FlushBuffer. We could redefine FlushBuffer as taking either a conditional or unconditional lock, but I think that's a weirder API than a flag to say the lock is already taken. 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly