On Mon, 2003-11-03 at 10:00, Tom Lane wrote:
> I do not actually agree with the "UnlockAndReleaseBuffer" changes
> anyway. I think this obscures the code by making resource grabbing
> and resource releasing code unsymmetrical
Hmm... fair enough, I see your point. In that case, should I remove the
UnlockAndReleaseBuffer macro and change all the places that use it to
just do a LockBuffer() followed by ReleaseBuffer()?
(Similarly for UnlockAndWriteBuffer())
> not to mention incompatible
> with code branches where the unlock and the buffer release can't be
> merged because other things are done in between.
This makes no sense to me: the macro is inapplicable in this case, but I
don't see how this makes anything "incompatible". Can you elaborate?
> As for removing the BM_TRACE code, what's broken about it? Shouldn't we
> be more interested in fixing it than removing it?
Well, it doesn't compile, and probably hasn't for years, so I took that
as a sign that there wasn't much interest in it. We need proper buffer
tracing, but if anyone wants to implement that, the first thing they'd
need to do is rip out the existing, broken BMTRACE code. In the unlikely
event that someone would like to resurrect it or use it for reference,
that's what CVS is for...
-Neil
