Re: Bug in new buffer freelist code - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bug in new buffer freelist code
Date
Msg-id 20478.1073501274@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug in new buffer freelist code  (Neil Conway <neilc@samurai.com>)
Responses Re: Bug in new buffer freelist code  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
Neil Conway <neilc@samurai.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> It might also be worthwhile to add another BM_FLAG bit that
>> specifically indicates a buffer is on the freelist, and
>> set/clear/test that at appropriate spots.

> ISTM that BM_FREE should indicate this, or am I misunderstanding you?

No.  BM_FREE means refcount == 0.  In the old implementation this meant
it was "on the freelist", but in the ARC code there are several
"freelists".  I was speaking specifically of the freelist that's used to
hold completely-dead buffers (buffers not containing any valid page).

It might be a good idea to rename BM_FREE to something else, perhaps
BM_UNPINNED, since I can recall being confused about what it meant too.

Also, if Jan likes the idea of adding a flag bit for this purpose, maybe
there should be a flag bit associated with each of the ARC freelists,
so you can tell positively where a "free" buffer is supposed to be.

The dead-buffer freelist may not need a flag bit per se, since the
condition of the buffertag being "clear" should be equivalent.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: Bug in new buffer freelist code
Next
From: Andrew Dunstan
Date:
Subject: Re: Brokenness in parsing of pg_hba.conf