Re: 'COPY ... FROM' inserts to btree, blocks on buffer writeout

Simon Riggs <simon(at)2ndquadrant(dot)com> 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