Re: backup_label revisited

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: backup_label revisited
Date: 2014-06-02 13:10:27
Message-ID: CAHGQGwGfbDa2iL9ZEqrDhX4Kk9cjho1HUxv_tnUkCR4tBvzwFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 29, 2014 at 9:12 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> So I ran into the case again where a system crashed while a hot backup
> was being taken. Postgres couldn't start up automatically because the
> backup_label was present. This has come up before e.g.
> http://www.postgresql.org/message-id/CAAZKuFaP1GxcOJtyzCh13rvevJeVwro1VVfbYsQTWGUD9iS1_g@mail.gmail.com
> but I believe no progress was made.
>
> I was trying to think if we could somehow identify if the backup_label
> was from a backup in progress or a restore in progress. Obvious
> choices like putting the server ip address in it are obviously not
> going to work for several reasons.
>
> However, at least on Linux wouldn't it be sufficient to put the inode
> number of the backup_label file in the backup_label? If it's still the
> same inode then it's just restarting, not a restore since afaik
> there's no way for tar or the like to recreate the file with the same
> inode on any filesystem.

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?

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Serge Negodyuck 2014-06-02 13:18:13 Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby
Previous Message Michael Paquier 2014-06-02 12:55:35 Re: WAL replay bugs