Move a record without losing its address

The byte lesson gave each record a length. Now the shop changes a product name from “Tote” to “Canvas tote.” The new text needs more room. If other records occupy the following bytes, we cannot simply extend the name into them.

An engine needs to move records while keeping references to them meaningful. We will work inside one fixed-size block of a file, called a page. The next stage explains how pages move into memory; here we only examine their byte layout.

Put a small directory in front of the records

Instead of recording a product’s byte offset everywhere, give it a numbered slot inside its page. The slot stores the record’s current offset and length. A reference can then name the page and slot.

In our invented 128-byte page, slot 2 points to a 12-byte record beginning at offset 80. Assume the page also has a free 20-byte region beginning at offset 100. The lengths include the record’s other fields and header; these are illustrative layout values.

Before growth
Reference: page 7, slot 2
Slot 2: offset 80, length 12
Record occupies bytes 80–91

After growth
Reference: page 7, slot 2
Slot 2: offset 100, length 20
Record occupies bytes 100–119

The record moves. Its page-and-slot reference stays the same because the directory entry changes with it.

To read the record, first find page 7, then read slot 2, then use that entry’s offset and length. This extra lookup separates identity from placement. We call the layout a slotted page.

Move bytes under explicit rules

For this example, only one operation accesses the page at a time. It prepares the larger record in free space, changes the slot entry, and makes the old space reusable. A reader must not observe a new offset paired with an old length. Concurrency and recovery will later supply the coordination for those steps; moving bytes alone does not make the update crash-safe.

The reader also checks bounds. An offset of 120 with length 20 would extend beyond our 128-byte page. Following it blindly would interpret unrelated memory or damaged data. A corrupt slot should produce a controlled error.

Our stable-reference claim is deliberately local. Moving the record to a different page needs another rule, such as updating references or leaving a forwarding entry. Reusing a deleted slot also requires care: an old reference must not silently become a reference to an unrelated new product.

Check the space calculation

Suppose a record needs 24 bytes, but the page’s free regions contain 10 and 18 bytes. Is a direct placement possible?

Distinguish total space from one usable region

There are 28 free bytes in total, but neither region can hold 24 consecutive bytes. The engine could rearrange records to combine free space, using the slot directory to update their locations. If it cannot make a suitable region safely, it must use another placement strategy.

The directory gives us room to reorganize storage without making every reference a raw address. Next we will treat the page as a unit that can be loaded, used, and replaced in memory.

PostgreSQL’s page-layout documentation shows a real item-directory design. Our page size and relocation example are teaching choices, not its exact update protocol.

Extended reference

The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.

Find a section from the original chapter