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
cleanly.
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
http://www.postgresql.org/message-id/F93E42280A9A4A5EB74FC7350C801A20%40maumau
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:
http://www.postgresql.org/mailpref/pgsql-hackers
