RedBase Project Frequently Asked Questions

Modifying previous components

It's very common to make changes to earlier components after you've submitted them. You're welcome to do so as long as you don't change the portions of the interfaces we specified. You may also modify the PF component if you like, as long as you don't modify how I/O statistics are kept. If you do make changes, please turn in the new files with your next submitted component, so we always have the latest files for your project.

String-valued attributes and string comparisons

When a RedBase attribute value is specified as a character string of length n, then it contains n valid characters, even if some of them are the null termination character "\0". For example, suppose we have an attribute that is a character string of length 8. Strings "hello\0\0\0" and "hello\01\0" are both 8-character strings, and "hello\0\0\0 < hello\01\0" should evaluate to true (even though they look the same when printed).

When comparing strings of different lengths, the easiest approach is to make both strings the same length by padding the shorter one with "\0" characters to match the length of the longer one. For example, to compare "hello" with "helloworld" you can pad "hello" to "hello\0\0\0\0\0" then check "hello\0\0\0\0\0 < helloworld".

Use of Memory in RedBase

One way to win the RedBase I/O Efficiency Contest without increasing the size of the PF buffer pool is to allocate a separate chunk of memory that's used for your own separately-managed large buffer pool (for pages, records, whatever). Obviously doing so is not allowed as far as the contest is concerned. For the contest, if you wish to store data from the database in allocated memory you have two options:

  1. You are permitted to allocate small amounts of memory, e.g., to store a fixed amount of header information or a couple of records at a time.

  2. If you want to allocate memory for full pages of records or other data, e.g., to implement a nested-block or RID-based join, you can use the "scratch pages" feature in the PF Component (see the PF specification for details). Every time you need a page worth of scratch memory, call PF_Manager::AllocateBlock, which allocates a pinned page of memory in the buffer pool and returns a pointer to it. When you are done using the scratch memory, call PF_Manager::DisposeBlock on this pointer to release the buffer page.

You are welcome to implement data caching mechanisms that do not use the buffer, either now or in your extension, but please disable such mechanisms when you turn in your basic project if you want to enter the contest.

Feel free to contact the instructor or TA if you have specific questions about this policy as it relates to your own implementation.

Using Valgrind

Valgrind is an excellent tool for the C/C++ programmer to help find run-time memory leaks and corruption errors. It detects reading or writing beyond the bounds of an array or within freed memory. It detects memory leaks as well as any attempts to free memory multiple times. Valgrind instruments the binary at run time, so there is no need to modify your Makefile.

The Valgrind Quick Start Guide includes some information on how to run your program under Valgrind. We are requiring the use of Valgrind before submitting your programs (and before heading to the TA for debugging help!) because we strongly believe that it will help you create code that is more robust, it will help you find many common bugs very quickly, and it will enable you to focus your programming time on tackling the interesting database implementation issues in RedBase.