From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: backup_label revisited |
Date: | 2014-06-04 17:17:29 |
Message-ID: | CAM-w4HODJejOnLYYYcYF8vv+jNn1_FFP7K2jGFMO8=EtxYcRFg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 2, 2014 at 2:10 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> Could you let me know the link to the page explaining this?
>
>> That would even protect against another
>> restore on the same host.
>
> 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.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-06-04 17:21:46 | Re: pg_control is missing a field for LOBLKSIZE |
Previous Message | Pavel Stehule | 2014-06-04 16:22:25 | Re: psql: show only failed queries |