Re: Design notes for BufMgrLock rewrite

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> This design seems to be a clear improvement on the current design. I am
> still encouraged that the freelist structures should be subdivided into
> many smaller pieces, thereby producing finer grained locks (the earlier
> bufferpools proposal).

As I already said, I'm dubious about that idea because of the consequent
reduction of cache management efficiency (since any particular page has
to fight for survival in a smaller pool). It occurs to me however that
we could split up the BufMappingLock in a similar fashion at minimal
efficiency penalty.

The idea is to replace the global tag->buffer hash table by 2^N separate
tables; you determine which one to use based on the low-order N bits of
the hash code for the buffer tag, which you always know when accessing
these tables. Then give each of these tables its own lock. Essentially
this subdivides the buffer tag space into 2^N independent slices.

This does not quite work perfectly; the tricky part comes when
reclaiming a buffer for use as another page. In the patch as it stands,
once we've written out the prior buffer contents we can atomically
check for a conflict and reassign the buffer because we need only the
one BufMapping lock to do it. But with this idea the old and new
associations might belong to different tables. I think the logic would
have to be
lock old mapping table for buffer;
check buffer's not dirty (if so unlock and start over)
remove mapping from old table;
unlock old table;
// at this point we have pin on a completely unassigned buffer
lock new mapping table for buffer;
check for conflict against someone having already made same entry
if found, unlock, put buffer in freelist, use other buffer;
insert mapping into new table;
unlock new table;
This costs us an extra lock/unlock cycle, plus in case of a conflict
we end up having unnecessarily evicted a page from cache. But conflicts
should be pretty rare, so I think the penalty isn't that great.

I don't currently believe that we need this extra complexity, but I
thought I'd get the idea into the archives in case it does turn out
to be useful later.

regards, tom lane