pg_rewind: Remove recovery at the start of rewind
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:t253604psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 30, 2026 at 04:37 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 t253604_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 t253604_1 && git checkout t253604_1Patchset v1 (message #1) is on t253604_1
Hi,
I have been exploring whether pg_rewind can avoid running
crash recovery on a target that was stopped without a clean
shutdown, as at the end of rewind changed rel blocks and non
rel files are copied or removed wrt source.
Currently, pg_rewind starts the target in single-user mode to
complete crash recovery before rewind begins. This reads
all WALs from the last checkpoint and does the replay.
The attached POC instead scans target WAL directly.
pg_rewind already scans target WAL from the last common
checkpoint to construct the page map of blocks changed on
the target. This patch extends that processing to locate the
end of target WAL as well, so that pg_rewind can proceed
without starting postgres on the target.
The target is still required to be stopped. The patch rejects
a live target, removes a stale postmaster.pid when appropriate,
and removes --no-ensure-shutdown because pg_rewind no longer
runs crash recovery.
For locating the checkpoint preceding the divergence point, the normal
path follows the WAL record chain backwards from the divergence point.
The patch also has a fallback: if the record at the divergence point cannot
be read, it scans forward from the target control-file checkpoint, provided
that checkpoint precedes the divergence point.
The motivation is not to avoid reading target WAL. Both the current
implementation and the POC must read target WAL to build the page map.
The expected saving is avoiding redo of target WAL into relation files
that pg_rewind subsequently makes equal to the source, or removes because
they exist only on the target.
As a initial local benchmark, I compared current pg_rewind with this
POC. The workload generated approximately the following amount of
uncheckpointed target-side data:
current POC reduction
100 MB 1.404 s 0.979 s 30.3%
500 MB 5.358 s 3.991 s 25.5%
1000 MB 10.473 s 7.097 s 32.2%
2000 MB 49.904 s 31.294 s 37.3%
The result is a ~1.5x speedup in this workload, along with some tests
I did, and also make check-world passes.
would love to hear more thoughts on this.
--
Thanks :)
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/