Re: Recovery to backup point
От | MauMau |
---|---|
Тема | Re: Recovery to backup point |
Дата | |
Msg-id | 041D036C52454A5296896728D35B0537@maumau обсуждение исходный текст |
Ответ на | Re: Recovery to backup point (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: Recovery to backup point
|
Список | pgsql-hackers |
From: "Heikki Linnakangas" <hlinnakangas@vmware.com> > Thanks. Looks sane, although I don't much like the proposed interface to > trigger this, setting recovery_target_time='backup_point'. What the code > actually does is to stop recovery as soon as you reach consistency, which > might not have anything to do with a backup. If you set it on a warm > standby server, for example, it will end recovery as soon as it reaches > consistency, but there was probably no backup taken at that point. Thank you for reviewing so rapidly. I thought I would check the end of backup in recoveryStopsHere(), by matching XLOG_BACKUP_END and ControlFile->backupStartPoint for backups taken on the primary, and comparing the current redo location with ControlFile->backupEndPoint for backups taken on the standby. However, that would duplicate much code in XLOG_BACKUP_END redo processing and checkRecoveryConsistency(). Besides, the code works only when the user explicitly requests recovery to backup point, not when he starts the warm standby server. (I wonder I'm answering correctly.) > Hmm. I guess it's a nice work-around to use this option, but it doesn't > really solve the underlying issue. The system might well reach consistency > between deleting database files and the transaction commit, in which case > you still have the same problem. Yes, you're right. But I believe the trouble can be avoided most of the time. > It would be nice to have a more robust fix for that. Perhaps we could use > the safe_restartpoint machinery we have to not allow recovery to end until > we see the commit record. I was really hoping to get rid of that machinery > in 9.4, though, as it won't be needed for GIN and B-tree after the patches > I have in the current commitfest are committed. > > In any case, that's a separate discussion and separate patch. I think so, too. That still seems a bit difficult for what I am now. If someone starts a discussion in a separate thread, I'd like to join it. Regards MauMau
В списке pgsql-hackers по дате отправления: