fix: data and metadata size keep growing to infinity

[nqd]

Problem

The current system has an issue that does not recycle orphaned pages. At the end, the metadata file and data file keep increasing in sizes.

Data size and metadata size when inserting 2/6/20/200 million {EOAs+storages}

2.5G db2m
 32M db2m.meta
3.1G db6m
 64M db6m.meta
4.4G db20m
256M db20m.meta
 53G db200m
4.0G db200m.meta

With this PR the size for same tests:

428M db2m
128K db2m.meta
1.6G db6m
128K db6m.meta
4.0G db20m
128K db20m.meta

Why?

Let assume the orphan list has len 55603, and range [9390, 31720) was reclaimed.

At a transaction with snapshot_id = 5, a new orphaned page with orphaned_at=5 pushed into OrphanPages. This page would be inserted to the list with idx=9390. Other orphaned pages will also be pushed into this already reclaimed area. When the reclaimed area are full (idx 31719 is used), the program starts to push to the end of the list.

At the same transaction, the program pop() to allocate new pages. It first starts to look for pages at [31720, 55603); this range has orphaned_at <= snapshot_threshold (=4), then will be reclaimed. After reclaiming all pages at the right size, pop() looks for pages at the left. The left has range [0, i] where 9390 <= i < 31720, and list[i].orphaned_at = 5. The program looks at the end of pages on the left with idx=i, which has a failed condition (orphaned_at <= snapshot_threshold).

At the end of the transaction, orphan pages in [0, i] will not be reclaimed. This continues in the following transactions, makes the size of metafile grow up, also the data file with accumulated orphaned pages that do not get reused.

Proposal

This PR proposed a simple solution: Instead of always push() to the left of reclaimed area and pop() from the right of the orphaned part, we rotate the priority:

• when snapshot_id is even, push() to the left and pop() from the right first
• when snapshot_id is odd, push() to the right and pop() from the left first.
• snapshot_id is gradually increasing for each transaction, we have an equal chance of taking all orphaned pages. Only risk is when all transactions with odd snapshot_id orphan/recycle more pagers than all transactions with even snapshot_id; or other way around. This is unlikely for a real world scenario.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[nqd]

rename