On Thu, Mar 4, 2010 at 9:00 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> 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?
> This issue seems to still happen. So should this be fixed for 9.0?
> Or only writing a note in document is enough for 9.0? I'm leaning
> towards the latter.
I'm thinking of adding something like the following to the section
"25.6. Incrementally Updated Backups". Thought?
The pg_control file must be backed up first.
This avoids the problem that we might fail to restore a consistent
database state because recovery starts from the later restart point
than the start of the backup.
When recovering from the incrementally updated backup, the server
can begin accepting connections and complete the recovery successfully
before the database has become consistent. To avoid these problems,
you must check whether the database has been consistent by comparing
the progress of the recovery with the backup ending WAL location
before your users try to connect to the server and when archive
recovery ends. So, in advance, the backup ending WAL location must
be taken by calling the pg_last_xlog_replay_location function at the
end of the backup. The progress of the recovery is also taken from
the pg_last_xlog_replay_location function.
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
In response to
pgsql-docs by date
|Next:||From: Josh Kupershmidt||Date: 2010-03-29 16:34:46|
|Subject: confusing archive_command example|
|Previous:||From: Fujii Masao||Date: 2010-03-26 05:24:35|
|Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL|
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-03-26 15:05:02|
|Subject: Re: Postgres 9.0 Alpha, GIN indexes, and intarray contrib module, and SQL Functions |
|Previous:||From: Heikki Linnakangas||Date: 2010-03-26 12:23:48|
|Subject: Re: Streaming Replication and CopyOutResponse message|