On Wed, 14 Jun 2023 at 20:47, Robert Haas <robertmh...@gmail.com> wrote: > > A few years ago, I sketched out a design for incremental backup, but > no patch for incremental backup ever got committed. Instead, the whole > thing evolved into a project to add backup manifests, which are nice, > but not as nice as incremental backup would be. So I've decided to > have another go at incremental backup itself. Attached are some WIP > patches.
Nice, I like this idea. > Let me summarize the design and some open questions and > problems with it that I've discovered. I welcome problem reports and > test results from others, as well. Skimming through the 7th patch, I see claims that FSM is not fully WAL-logged and thus shouldn't be tracked, and so it indeed doesn't track those changes. I disagree with that decision: we now have support for custom resource managers, which may use the various forks for other purposes than those used in PostgreSQL right now. It would be a shame if data is lost because of the backup tool ignoring forks because the PostgreSQL project itself doesn't have post-recovery consistency guarantees in that fork. So, unless we document that WAL-logged changes in the FSM fork are actually not recoverable from backup, regardless of the type of contents, we should still keep track of the changes in the FSM fork and include the fork in our backups or only exclude those FSM updates that we know are safe to ignore. Kind regards, Matthias van de Meent Neon, Inc.