Message 28
Re: pinPage() and emptyPage != 0
X-Added: With Flames (bblib $Revision: 1.4 $)
Return-path: <lw2j+@andrew.cmu.edu>
X-Andrew-Authenticated-as: 31049;andrew.cmu.edu;Leejay Wu
Received: from po7.andrew.cmu.edu via trymail for bb+academic.cs.15-721@andrew.cmu.edu
ID </afs/andrew.cmu.edu/usr0/bb/Mailbox/svfHEDK00Udf1SgE40>;
Sat, 22 Sep 2001 20:59:59 -0400 (EDT)
Received: from unix5.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.4vfHD9u00UjBI1eEwa>;
Sat, 22 Sep 2001 20:58:49 -0400 (EDT)
Received: from unix5.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr9/lw2j/.Outgoing/QF.MvfHD9i00UjB5OSl9e>;
Sat, 22 Sep 2001 20:58:49 -0400 (EDT)
Received: from mms.4.60.Jul.16.2001.15.09.31.sun4.57.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.unix5.andrew.cmu.edu.sun4x.57
via MS.5.6.unix5.andrew.cmu.edu.sun4_57;
Sat, 22 Sep 2001 20:58:49 -0400 (EDT)
Message-ID: <wvfHD9e00UjBJOSl05@andrew.cmu.edu>
Date: Sat, 22 Sep 2001 20:58:49 -0400 (EDT)
From: Leejay Wu <lw2j+@andrew.cmu.edu>
X-Andrew-Message-Size: 1308+0
Content-Type: text/plain
If-Type-Unsupported: alter
To: Andrew BBoard Account <bb+academic.cs.15-721@andrew.cmu.edu>
Subject: Re: pinPage() and emptyPage != 0
Cc:
In-Reply-To: <MvfGz5_00UjIA1QUQG@andrew.cmu.edu>
References: <MvfGz5_00UjIA1QUQG@andrew.cmu.edu>
Excerpts from academic.cs.15-721: 22-Sep-101 pinPage() and emptyPage !=
0 by Aleksey Kliger
> What is the semantics of a call to pinPage with (emptyPage != 0) ?
>
> Does this just mean "do everything you would normally do to pin a
> page, except don't bother with the call to read_page(), because
> we know that the page is empty"?
> So does that mean that it's the Buffer Manager's responsibility
> to return a Page* to a page that _is_ actually empty (as opposed
> to having whatever random junk was in there from the last time
> that frame was used))? Or can the buffer manager just return a
> Page* to whatever frame it has around and assume that the caller
> will initialize the page contents as she sees fit?
Either way. In a real system, we'd want to zero out the frame
before letting it be reused, in order to avoid unauthorized
leaks of information, but that's not of great concern in a
database that doesn't implement any concept of identity, let
alone permissions. As it is, there's nothing stopping a random
client from methodically pinning, reading and randomizing each
page...
--
| lw2j@cs.cmu.edu | #include <0.0648g NaCl> |
|--------------------------|-----------------------------|
| #include <stddiscl.h> | Spam returned to postmaster |