3 The Minirel RDBMS

Minirel is a simple, multi-user RDBMS. It has all the features of a regular RDBMS, including concurrency control and locking, logging and recovery, buffer, heap file, and space management, access methods (B-trees, hashing, grid files, etc.), relational operators, query planning, and user interface components. The log manager fits into the system as follows:

• Every update operation will log its update via the recovery manager into the log tail. When the log tail is full or when there is a flush request, the log tail is flushed to disk.

• WAL is enforced by informing the buffer manager whenever the log tail is flushed. The buffer manager can also call the log manager to flush the log tail when it wants to flush a page whose page LSN is more than the last flushed LSN the buffer manager knows about.

• The recovery manager periodically writes checkpoint records into the log and calls the log manager to update the master log record.

• On restart, the recovery manager scans the log and performs restart recovery as described in Section 2.

Minirel is organized as follows: every Minirel process runs one transaction and accesses one database throughout its existence. There is one log corresponding to each database. (For simplicity, the log is maintained as a Unix file. Duplex-disks and log disks are not used.) Every Minirel process has the entire code for all components. However, the data portion (the buffer pool, the log tail, the lock and transaction tables, etc.) are kept in shared memory. The first transaction to use a database initializes all the shared data structures. Currently, a Minirel process uses only one database and its corresponding log. Thus, the shared memory data structures correspond to a common database.

We have made the following simplifications:

• No duplex-disks or raw device manipulation. We maintain the log as a single Unix file.

• A log tail of size one page. This considerably simplifies the implementation. Unfortunately, performance is not as good as it would have been with double buffering or multiple buffers.

• Complete ignorance of log record types. All that the log manager sees is a sequence of bytes. The recovery manager interprets the contents of a log record.

• No transaction ``crashes.'' If regular crashes were allowed and a transaction was in a critical section when it crashed (e.g., updating the log tail), no other transaction can enter its critical section. Thus, every transaction exits cleanly. However, cleanliness is restricted to unlocking shared data structures and exiting critical sections.