Incremental backup keeps VM bits cleared by VACUUM truncation
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:t254297psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 25, 2026 at 02:58 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 t254297_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 t254297_1 && git checkout t254297_1Patchset v1 (message #1) is on t254297_1
Hi,
With data_checksums and wal_log_hints off, a cluster restored from an
incremental backup can keep stale VM bits after VACUUM truncates a
table. When the table grows again, index-only scans return deleted and
rolled back rows.
The attached script shows it. One VACUUM empties the end of a table but
skips the truncation on a lock conflict. After the full backup, a later
VACUUM truncates it. On 17 and 18 the results stay wrong even after
another VACUUM. On 19 and master, VACUUM fixes them.
visibilitymap_prepare_truncate() clears bits in the last VM page, but
writes that page to WAL only if XLogHintBitIsNeeded(). So the WAL
summary never sees the change, and the incremental backup skips the
page.
0001 always writes the page to WAL, as Andres suggested in [1]/messages/by-id/t7xd6gjxdxpzdzr2uamfbyi5rlkdsikiywmtmgwrwcsr77xyw7@i3qhbzy5rpzx. Clusters
with checksums on already do this. 0002 adds a test that fails without
0001.
0001 and 0002 apply to master, 19 and 18. 17 needs the attached nocfbot
file.
The standby PANIC fix in [2]/messages/by-id/CAL4mQLAp562c1rCgg2Dqx6TBSdOk6vOvaLFjwFG9E6k4uwvJJw@mail.gmail.com touches the same code path but does
not cover this, so I am reporting it separately.
Command to run attached sh
sh incr-vm-truncate.sh /pgxxx/bin
[1]: /messages/by-id/t7xd6gjxdxpzdzr2uamfbyi5rlkdsikiywmtmgwrwcsr77xyw7@i3qhbzy5rpzx
/messages/by-id/t7xd6gjxdxpzdzr2uamfbyi5rlkdsikiywmtmgwrwcsr77xyw7@i3qhbzy5rpzx
[2]: /messages/by-id/CAL4mQLAp562c1rCgg2Dqx6TBSdOk6vOvaLFjwFG9E6k4uwvJJw@mail.gmail.com
/messages/by-id/CAL4mQLAp562c1rCgg2Dqx6TBSdOk6vOvaLFjwFG9E6k4uwvJJw@mail.gmail.com
Thanks for taking a look,
Shihao