Re: Recovery to backup point - Mailing list pgsql-hackers

From MauMau
Subject Re: Recovery to backup point
Date
Msg-id 041D036C52454A5296896728D35B0537@maumau
Whole thread Raw
In response to Re: Recovery to backup point  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Recovery to backup point
List 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 by date:

Previous
From: Euler Taveira
Date:
Subject: JSON decoding plugin
Next
From: Benedikt Grundmann
Date:
Subject: How to do fast performance timing