On 5/21/24 03:09, Robert Haas wrote:
> On Fri, May 17, 2024 at 6:14 PM David Steele <david@pgmasters.net> wrote:
>> Then intentionally corrupt a file in the incr backup:
>>
>> $ truncate -s 0 test/backup/incr1/base/5/3764_fsm
>>
>> In this case pg_verifybackup will error:
>>
>> $ pg_verifybackup test/backup/incr1
>> pg_verifybackup: error: "base/5/3764_fsm" has size 0 on disk but size
>> 24576 in the manifest
>>
>> But pg_combinebackup does not complain:
>>
>> $ pg_combinebackup test/backup/full test/backup/incr1 -o test/backup/combine
>> $ ls -lah test/backup/combine/base/5/3764_fsm
>> -rw------- 1 dev dialout 0 May 17 22:08 test/backup/combine/base/5/3764_fsm
>>
>> It would be nice if pg_combinebackup would (at least optionally but
>> prefferrably by default) complain in this case rather than the user
>> needing to separately run pg_verifybackup.
>
> My first reaction here is that it would be better to have people run
> pg_verifybackup for this. If we try to do this in pg_combinebackup,
> we're either going to be quite limited in the amount of validation we
> can do (which might lure users into a false sense of security) or
> we're going to make things quite a bit more complicated and expensive.
>
> Perhaps there's something here that is worth doing; I haven't thought
> about this deeply and can't really do so at present. I do believe in
> reasonable error detection, which I hope goes without saying, but I
> also believe strongly in orthogonality: a tool should do one job and
> do it as well as possible.
OK, that seems like a good place to leave this for now.
Regards,
-David