Re: bufmgr code cleanup

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: bufmgr code cleanup
Date: 2003-11-03 17:01:20
Message-ID: 1067878880.3089.373.camel@tokyo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-11-03 21:39:33 Re: equal() perf tweak
Previous Message Neil Conway 2003-11-03 16:47:55 Re: equal() perf tweak