On 12/09/2013 02:03 PM, MauMau wrote:
From: "Michael Paquier" <michael.paqu...@gmail.com>
As far as I recall, I don't think so. The problem and the way to solve
that are clear. The only trick is to be sure that recovery is done
just until a consistent point is reached, and to implement that

May I implement this feature and submit a patch for the next
commitfest if I have time?
Please feel free. I might as well participate in the review.

I've done with the attached patch.

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.

 I also confirmed that the problem I
raised in the first mail of the below thread was solved with this patch.

[bug fix] PITR corrupts the database cluster

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.

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.

- Heikki

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to