Re: Incremental backups report progress as if they were full backups

Hi,

On Tue, Oct 13, 2026 at 5:45 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> 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.