Add test_bufmgr - algorithm-agnostic tests for the buffer manager
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253309psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 23, 2026 at 03:44 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253309_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253309_1 && git checkout t253309_1Patchset v1 (message #1) is on t253309_1
Hi Hackers,
I was looking at Greg's (cc'd) work around buffer management and
thought of contributing there to review the patch and add some tests.
Thanks Greg for encouraging and suggesting to write this test module
instead.
This is an eviction algorithm agnostic test module to test buffer manager
general properties.
The buffer manager (src/backend/storage/buffer/) has no test module of
its own. It is exercised constantly by the rest of the regression
suite, but only incidentally and nothing asserts its properties directly,
so a change to the replacement policy or to the residency bookkeeping
might regress without any test noticing.
The attached patch adds src/test/modules/test_bufmgr. The framing I
would like to put up front, because it drove most of the design: this
tests the buffer manager as a subsystem, not any one replacement
algorithm. The module is named for the subsystem under test, which is
stable, rather than for the current eviction policy, which keeps changing.
More details on use cases tested and parameters used to run tests are added
to README. I would appreciate review, particularly on whether the
properties I have
picked are the right set, and on whether the pressure-generation
approach is robust enough for the buildfarm's range of configurations.
Thanks,
Dinesh Salve
A quick follow up note - I had checked which of these properties are
already covered elsewhere in the
tree. Some are, and I have kept them here deliberately to assert
them directly treating this as a complete test, please let me know if this
doesn't sound right.
New, not asserted anywhere today IMO:
- pinned_safety: a pinned shared buffer is never chosen as a victim.
- scan_no_retain: a one-touch page does not indefinitely retain its buffer.
- churn: contents stay correct across many pool-wide reload cycles.
- eviction_reload: an evicted page reloads correctly and the manager makes
progress under pressure.