Re: Problem with streaming replication, backups, and recovery (9.0.x)
От | Heikki Linnakangas |
---|---|
Тема | Re: Problem with streaming replication, backups, and recovery (9.0.x) |
Дата | |
Msg-id | 4D9200A9.5090406@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Problem with streaming replication, backups, and recovery (9.0.x) (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Problem with streaming replication, backups, and
recovery (9.0.x)
|
Список | pgsql-hackers |
On 29.03.2011 14:27, Fujii Masao wrote: > On Tue, Mar 29, 2011 at 6:46 PM, hubert depesz lubaczewski > <depesz@depesz.com> wrote: >>> Did you use recovery.conf to start standalone PostgreSQL? If not, >>> recovery doesn't check whether it reaches the recovery ending position >>> or not. So I guess no problem didn't happen. >> >> no, i don't use. >> >> hmm .. i am nearly 100% certain that previous pgs did in fact check if the end >> of recovery is reached. > > Yes. In 8.4, that was checked only when starting recovery from the backup > (i.e., which includes backup_label and backup history file) without > recovery.conf. > But in 9.0, the behavior was changed so that only archive recovery (i.e., with > recovery.conf) checks that. IIRC, we don't have strong opinion about > this change. > We should revert, in order to make even crash recovery check whether it > reaches the ending location? Hmm, why did we change that? It seems like a mistake, the database is not consistent until you reach the backup stop location, whether or not you're doing archive recovery. +1 for reverting that, and backpatching it as well. "pg_basebackup -x", which includes all the WAL required to restore in the pg_xlog directory of the base backup itself, is also affected. Without the check that you reach the end-of-backup, an aborted base backup will appear to restore fine, even though some WAL segments are missing and the backup is incomplete. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: