Thanks Mahendra, a minor observation - The pg_restore output shows a double slash in the map.dat path (e.g., abc.tar//map.dat).
While it doesn't break the restore, we may want to clean up the path joining logic.
[edb@1a1c15437e7c bin]$ ./pg_restore -Ft -C abc.tar/ -d postgres -p 9011 -U ed -v
pg_restore: found database "template1
" (OID: 1) in file "abc.tar//map.dat"
pg_restore: found database "postgres
" (OID: 5) in file "abc.tar//map.dat"
Please refer to this scenario where - Objects created under template1 and the postgres database by a specific user are failing during a cross-cluster restore.
When restoring to a new cluster as a different superuser, pg_restore throws the error: ERROR: role "edb" does not exist.
It appears the restore is attempting to preserve the original ownership of template1 objects even when the target environment lacks those specific roles.
Steps to reproduce:
initdb ( ./initdb -U edb -D data) , start the server , connect to postgres and template1 database one by one and create
this table ( create table test(n int); )
perform pg_dumpall operation ( ./pg_dumpall -Ft -f abc.tar)
initdb (./initdb -U xyz) , start the server , create a database ( create database abc;)
perform pg_restore operation ( ./pg_restore -Ft -C abc.tar/ -d postgres -p 9033 -U xyz)
--getting an error, table 'test' will be created on 'template1' database but failed to create on an another database ( in this case - 'abc' database)
regards,
