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

Hi Fujii,

> 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.
>

Thanks for splitting the patch. The split looks good to me.
The compression wording applies to every base backup since v15, and the
estimate fix only matters for incremental backups, which arrived in v17.

I looked through both patches and few observations:
1. 0001 applies cleanly to master and to REL_15_STABLE through
REL_18_STABLE, and 0002 applies on top of it on master, REL_17_STABLE and
REL_18_STABLE.
2. The new wording in 0001 matches the code on all of those branches. The
progress sink sits above the compression sinks, so the counters measure
data before compression.
3. Your fix to the progress report message description is right, too.
bytes_done is only reset when the backup starts, so the message
carries a running total for the whole backup, not a per-tablespace count.
4. The code in 0002 is the same as in v3, apart from how the pfree() is
written.

I also reran the tests on master (158b6d5109f) with v4 applied. The new
test passes, and still fails with either half of the fix reverted,
with the same numbers as with v3. Since the CHECKPOINTs were removed, I
ran it five times in a row, and it passed every time. An incremental
backup with --compress=server-gzip ends at 100%, and the pg_basebackup and
pg_combinebackup suites pass.

v4 looks good to me.

Regards,
Surya Poondla