Prev: [HACKERS] Deadlock in vacuum (check fails)
Next: [HACKERS] Hot Standby and query cancel
From: Fujii Masao on 13 Jan 2010 06:57
On Wed, Jan 13, 2010 at 8:36 PM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> Our documentation suggests that you can take a base backup of a warm
> standby server while it's running:
>
>> If we take a backup of the standby server's data directory while it is processing logs shipped from the primary, we will be able to reload that data and restart the standby's recovery process from the last restart point. We no longer need to keep WAL files from before the restart point. If we need to recover, it will be faster to recover from the incrementally updated backup than from the original base backup.
>
> That doesn't seem safe. If the server makes a new restartpoint while the
> backup is running, and pg_control is backed up after the new
> restartpoint is made, recovery will restart from the new restartpoint.
> That is wrong; recovery needs to restart at the restartpoint that was
> most recent when the backup started. This is basically the same issue we
> have solved in master with the backup_label file.

Right.

> I wonder if it would be enough to document that pg_control must be
> backed up first?

Probably No. The archive recovery from such base backup would always
fail at the end of recovery because there is no backup-end record,
i.e., pg_stop_backup() is not executed in that case.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on 13 Jan 2010 07:34
Fujii Masao wrote:
> On Wed, Jan 13, 2010 at 8:36 PM, Heikki Linnakangas
> <heikki.linnakangas(a)enterprisedb.com> wrote:
>> I wonder if it would be enough to document that pg_control must be
>> backed up first?
>
> Probably No. The archive recovery from such base backup would always
> fail at the end of recovery because there is no backup-end record,
> i.e., pg_stop_backup() is not executed in that case.

No, that's not an issue. We only wait for the backup-end record if we
haven't seen yet since we started recovery from the base backup.
Assuming the standby had reached that point already before the new
backup from the standby started, backupStartLoc is zero in the control file.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Fujii Masao on 13 Jan 2010 17:13
On Wed, Jan 13, 2010 at 9:34 PM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> No, that's not an issue. We only wait for the backup-end record if we
> haven't seen yet since we started recovery from the base backup.
> Assuming the standby had reached that point already before the new
> backup from the standby started, backupStartLoc is zero in the control file.

OK. That assumption should be documented?

And, when we start an archive recovery from the backup from the standby,
we seem to reach a safe starting point before database has actually become
consistent. It's because backupStartLoc is zero. Isn't this an issue?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: [HACKERS] Deadlock in vacuum (check fails)
Next: [HACKERS] Hot Standby and query cancel