Collaboration diagram for How Log Sequence Numbers are Used:
Detailed Description
A log sequence number generally points to a record in the log. It consists of two parts:
- hi(), a.k.a., file(). This is a number that matches a log partition file, e.g., "log.<file>"
- lo(), a.k.a., rba(). This is byte-offset into the log partition, and is the first byte of a log record, or is the first byte after the last log record in the file (where the next log record could be written).
- Note:
- Once the database runs long enough we will run out of partition numbers (only 64k possible). Fortunately, this is a log, so lsn_t don't last forever. Eventually things become durable and the log partition file gets reclaimed (deleted). As long as the first partition is gone before the last one fills, we can simply wrap and change the sense of lsn_t comparisions.
A savepoint (sm_save_point_t) is an lsn_t. It tells how far back a transaction should undo its actions when ss_m::rollback_work is called.
Each page has an lsn_t that acts as a timestamp; it is the lsn of the last log record that describes an update to the page.
In recovery, when a page is read in, all log records with sequence numbers less than the page lsn have been applied, and redo of these log records is not necessary.
The storage manager has other special cases: lsn_t(0,1) -- this is in page.cpp, page_p::_format(), and indicates a freshly formatted page with no further updates.
Pages have two copies of their page lsn; one at the head and one at the end of the page. Presumably if the two match, the page is uncorrupted, though that is no guarantee. Certainly if they do not match, something is wrong.
The buffer pool's control blocks (bfcb_t) contain an lsn_t, the "recovery lsn" or rec_lsn. This is a timestamp that can be compared with the page lsns to determine if the copy in the buffer pool is up-to-date or not.
A recovery lsn is a lower bound on the lsn of a log record that updated the page in the frame. A clean page in the buffer pool has a rec_lsn of lsn_t::null. Each time a page is fixed in EX mode, the buffer control block ensures that the rec_lsn is not lsn_t::null, thereby indicating that this page is probably dirty and needs flushing or, possibly, is being flushed. The rec_lsn is set to the tail of the log at the time the fix is done; this ensures that any log record written for an update to the page has at least the rec_lsn sequence number. There might be several updates to the page before the page is cleaned, so the rec_lsn is indeed a lower bound, and that's all we can know about it.
Special cases of log sequence numbers:
- null: not a valid lsn_t
- max: soon to overflow
- lsn(0,1) : used when some pages are formatted.
Generated on Wed Jul 7 17:22:38 2010 for Shore Storage Manager by
1.4.7
