Hi Daria, Thanks for v3.
I tested it on master (8e82d6610e7). To check the new test, I reverted each half of the fix in turn and reran it: 1. Without the sendTablespace() change, the backup ended at 3811/14478 kB. Only your new check caught this; the comparison with the full backup still passed, just as you said. 2. Without the sendDir() change, it ended at 3811/24251 kB, and both checks failed. 3. With the full patch, it ended at 3811/3811 kB. So the test now covers both halves of the fix. I also tried an incremental backup with --compress=server-gzip, and it ends at 100% as well. The pg_basebackup and pg_combinebackup test suites pass. Regarding compression, thanks for explaining. You're right that compression doesn't throw off the percentage, since both numbers are counted before compression. My concern was only the wording. On your question about the "streamed" wording: the --no-estimate-size sentence is new in this patch (before, it said "enumerating the size of the entire database"), so I'd change it to match the new wording. Something like "estimating the total amount of archive data that will be generated". The monitoring.sgml text is older and says "streamed" for both backup_total and backup_streamed, so I'd leave it for a separate patch, if anyone thinks it's worth changing. One small leftover: the comment in perform_base_backup() still says + * Calculate the total backup size by summing up the amount of data + * that will be sent for each tablespace which could say "archive data" too. Your reasoning on keeping the test in its own file, and on the back branches, makes sense to me. Regards, Surya Poondla
