On Fri, Dec 17, 2010 at 3:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Yeah. I think that BM_UNLOGGED might be a poor choice for the flag name,
>>> just because it overstates what the bufmgr needs to assume.
>
>> I was actually thinking of adding BM_UNLOGGED even before this
>> discussion, because that would allow unlogged buffers to be excluded
>> from non-shutdown checkpoints. We could add two flags with different
>> semantics that take on, under present rules, the same value, but I'd
>> be disinclined to burn the extra bit without a concrete need.
>
> bufmgr is currently using eight bits out of a 16-bit flag field, and
> IIRC at least five of those have been there since the beginning. So our
> accretion rate is something like one bit every four years. I think not
> being willing to use two bits to describe two unrelated behaviors is
> penny-wise and pound-foolish --- bufmgr is already complicated enough,
> let's not add useless barriers to readability.
Allright, what do you want to call the other bit, then? BM_SKIP_XLOG_FLUSH?
I have a feeling we may also be creating BM_UNTIDY rather soon, per
previous discussion of hint bit I/O.
Since these bits will only be set/cleared when the buffer mapping is
changed, can we examine this bit without taking the spinlock? If not,
we're going to have to stick an extra spinlock acquire/release into
FlushBuffer(), which sounds rather unappealing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company