Hi, On Tue, Oct 13, 2026 at 5:45 PM Fujii Masao <[email protected]> wrote: > The documentation clarification below about the relationship between > estimated backup size and compression addresses a separate issue from the > incorrect progress reporting for incremental backups: > > + The approximate size of the archive that will be generated for the > + tablespace, in kilobytes (1024 bytes), before any server-side > + compression, if progress report has been requested; otherwise it's > > Rather than combining both fixes in one patch, how about splitting them into > two patches? They address separate issues and have different backpatch > ranges. The documentation clarification should be backpatched to v15, where > server-side compression was introduced, while the incremental backup > progress fix should be backpatched to v17. > > I've created both patches based on v3 patch and attached them. > For the 0002 patch, I've also made some cosmetic changes and > cleaned up the tests.
Thank you for splitting the patch and for preparing both versions yourself. Agreed, we got a bit carried away and ended up touching two separate issues in one patch. The split and the resulting backpatch ranges make sense to me. I have no objections to the contents of either patch. I checked two points independently. The clarification about the progress report’s byte count applies as far back as v15: bytes_done is initialized to zero once, at the start of the backup, and the progress message carries state->bytes_done unchanged, so the count has always been cumulative rather than per tablespace. The compression wording is also accurate for v15 and v16, where the progress sink is created above the compression sinks, so the counters measure archive data before compression on those branches too. I got the same results as Surya. I also checked the branch ranges myself: patch 0001 applies to REL_15_STABLE through REL_18_STABLE, and patch 0002 applies on top of it to REL_17_STABLE and REL_18_STABLE. Since the CHECKPOINTs have been removed from the test, I ran it twenty times in a row rather than five, with no failures, and the totals are the same as with v3: 34694/34694 kB for the full backup and 3811/3811 kB for the incremental one. And I also tested a larger cluster outside the test suite, since the test only uses small relations. With a 20 GB table spread over twenty segments in a separate tablespace and fifty rows changed in the last segment, the full backup ends at 21684624/21684624 kB and the incremental backup at 9606/9606 kB. Nineteen of the twenty segments are sent as 12-byte incremental files, while the twentieth contains 72 kB of changed blocks. None of the segments is sent in full. pg_combinebackup reconstructs the chain, pg_verifybackup passes, and the restored data matches.
