Hi, In a negative test scenario, if I changed size to -1 in backup_manifest, pg_validatebackup giving error with a random size number.
[edb@localhost bin]$ ./pg_basebackup -p 5551 -D /tmp/bold --manifest-checksum 'SHA256' [edb@localhost bin]$ ./pg_validatebackup /tmp/bold pg_validatebackup: backup successfully verified --change a file size to -1 and generate new checksum. [edb@localhost bin]$ vi /tmp/bold/backup_manifest [edb@localhost bin]$ shasum -a256 /tmp/bold/backup_manifest c3d7838cbbf991c6108f9c1ab78f673c20d8073114500f14da6ed07ede2dc44a /tmp/bold/backup_manifest [edb@localhost bin]$ vi /tmp/bold/backup_manifest [edb@localhost bin]$ ./pg_validatebackup /tmp/bold pg_validatebackup: error: "global/4183" has size 0 on disk but size *18446744073709551615* in the manifest Thanks & Regards, Rajkumar Raghuwanshi On Thu, Mar 5, 2020 at 9:37 AM Suraj Kharage <suraj.khar...@enterprisedb.com> wrote: > > On Wed, Mar 4, 2020 at 7:21 PM tushar <tushar.ah...@enterprisedb.com> > wrote: > >> Hi, >> >> There is a scenario in which i add something inside the pg_tablespace >> directory , i am getting an error like- >> >> pg_validatebackup: * manifest_checksum = >> 77ddacb4e7e02e2b880792a19a3adf09266dd88553dd15cfd0c22caee7d9cc04 >> pg_validatebackup: error: "pg_tblspc/16385/*PG_13_202002271*/test" is >> present on disk but not in the manifest >> >> but if i remove 'PG_13_202002271 ' directory then there is no error >> >> [centos@tushar-ldap-docker bin]$ ./pg_validatebackup data >> pg_validatebackup: * manifest_checksum = >> 77ddacb4e7e02e2b880792a19a3adf09266dd88553dd15cfd0c22caee7d9cc04 >> pg_validatebackup: backup successfully verified >> >> > This seems expected considering current design as we don't log the > directory entries in backup_manifest. In your case, you have tablespace > with no objects (empty tablespace) then backup_manifest does not have any > entry for this hence when you remove this tablespace directory, validator > could not detect it. > > We can either document it or add the entry for directories in the > manifest. Robert may have a better idea on this. > > -- > -- > > Thanks & Regards, > Suraj kharage, > EnterpriseDB Corporation, > The Postgres Database Company. >
