Message 10

Re: What is the intended behavior of flushPage() and flushAllPages()

Message-ID: <8vdtpbC00UjIJKv2sT@andrew.cmu.edu>
Date: Tue, 18 Sep 2001 15:15:51 -0400 (EDT)
From: Leejay Wu <lw2j+@andrew.cmu.edu>
To: "cyrus.academic.cs.15-721" <post+academic.cs.15-721@andrew.cmu.edu>
Subject: Re: What is the intended behavior of flushPage() and flushAllPages()
Cc: 
In-Reply-To: <Pine.GSO.4.33L-022.0109181256520.16305-100000@unix3.andrew.cmu.edu>
References: <Pine.GSO.4.33L-022.0109181256520.16305-100000@unix3.andrew.cmu.edu>

Excerpts from academic.cs.15-721: 18-Sep-101 What is the intended
behavi.. by Thomas Wenisch@andrew.cm 
>         Test 4 seems to want "flush" to mean "empty the buffers".  
> In other words, flushing means marking the page as not present, 
> reset the LRU stack (since all pages are now available, LRU is
> meaningless), and all subsequent pins force pages to be loaded 
> from disk.  This further implies that flushing a pinned page is 
> illegal, since a pinned page can't be "ejected" from its buffer.  
> (My current implementation allows flushing a pinned page.  It 
> gets written to disk and the dirty bit is cleared, which may 
> then get set again when the page is unpinned).  If flushing a 

The issue with this behavior is that whoever's got a page 
pinned, still has what they perceive as a perfectly valid 
memory pointer.  Since writes via that pointer occur
directly, and not through the BufMgr interface, theoretically
a client programming error (or concurrency, if that were an
issue here) could cause somebody to write to the pointer later.  
In the best case, the write simply doesn't get committed 
because the BufMgr doesn't know about it (and will return an
error when the client tries to unpin it); a worse case is
that somebody else pins a different database page into the 
same frame before the errant write, and the write basically
hits a random database page.  Ugh.

> pinned page is illegal, what should the behavior of flushAll() 
> be?  Should it skip pinned pages and flush unpinned ones, or 
> should the call fail?

Good question.

If a page is pinned, flushAll() should fail.  The solution 
will in this case still flush (write to disk, and remove from
buffer) all unpinned, dirty pages.

In the case of BMTester.C's test4(), I don't believe that this 
should actually happen (failed flushAll()) because every page 
in the buffer should be a) dirty, and b) unpinned.

Reading the provided key, I see that it cheerfully flushed even
pinned, dirty pages to disk, which is problematic for the 
reasons outlined above... and I suspect that the Minibase
distribution also includes the little "issue".  A saner 
behavior seems to me to be:

- If a page is pinned, don't do anything with it, because in
  theory somebody might still want to write to that frame... 
  and we won't know if they do, because they've got direct 
  access via a pointer.

  When we return, return an error.

- If a page is unpinned:
  - If the page is dirty, write it to disk.
  - Remove it from the buffer, clean or dirty.  That is,
    the frame is now considered to hold a clean, invalid
    page.

If the call is merely to flush a single page, then the 
main failure modes (besides consistency problems) are the
page not being in the buffer at all, or it being pinned.

I'll update the key (which will be in libwith.a) to implement
this approach.  For another design decision, I'll have the 
loop not exit immediately if a pinned page is encountered --
IOW, it'll still flush unpinned pages, but will return a
failure in the end.  Alternately, you can have the function
simply check first, and not flush any buffers if any page
is pinned; the former may be better when one is concerned 
about buggy / malicious clients that never unpin a page, 
while the latter approach seems applicable if the database
itself is calling flushAllPages() at a point where all pages
*should* have been unpinned already, and a pin indicates a
logic error of some sort.

The BMTester.C does _not_ differentiate between these, since 
as noted before all pages should be dirty and unpinned, and
the LRU ordering only matters before the flush (so you can
reset the LRU queue if you choose) -- the reloading after
the flush is merely to check that the pages were indeed 
written correctly.

-- 
|   lw2j@cs.cmu.edu        | #include <0.0648g NaCl>     |              
|--------------------------|-----------------------------|  
|   #include <stddiscl.h>  | Spam returned to postmaster |