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
