On Wed, Jun 04, 2014 at 06:17:29PM +0100, Greg Stark wrote: > On Mon, Jun 2, 2014 at 2:10 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > > What about the case where we restore the backup to another server and > > start the recovery? In this case, ISTM inode can be the same. No? > > Hm, I was about to comment that that seems very unlikely. Even on the > same server if you delete the old database root and then unpack a > backup it could possibly reuse the exact same inode again. But it's > really not likely to happen. > > However in the brave new world of filesystem snapshots there is the > possibility someone has "restored" a backup by opening one of their > snapshots read-write. In which case the backup-label would have the > same inode number. That would still be fine if the snapshot is > consistent but if they have tablespaces and those tablespaces were > snapshotted separately then it wouldn't be ok. > > I think that's a fatal flaw unless anyone can see a way to distinguish > a filesystem from a snapshot of the filesystem.
Implementations of the "dump" program likely have that property of preserving inode metadata while not promising a consistent snapshot. If we keep such backup methods fully supported, I agree with your conclusion. PostgreSQL can't, in general, distinguish an almost-snapshot from a master that crashed during a backup. But the administrator can track the difference. If you use pg_start_backup(), your init.d script that gets control after a crash can have 'rm -f "$PGDATA"/backup_label'. Use a different script to recover hot backups. Perhaps what ought to change is the documentation and contrib/start-scripts? Maybe even add a --definitely-not-a-backup postmaster option, so scripts need not hardcode knowledge of a semi-internal fact like the name of the file to delete. Thanks, nm -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers