On Fri, Dec 17, 2010 at 3:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
