On 26 April 2013 11:29, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> But there is also an operation to simply "restore a backup".
Just because a tool supports an imprecise definition of a restore,
doesn't mean Postgres should encourage and support that.
"Restore a backup" is more suited to filesystems where most files
don't change much. And its also a common user complaint: "I restored
my back but now I've lost my changes. Can you help?". That's not
something that's been heard around here because we don't encourage
foot-guns.
> One solution is to create restore point after the backup ends. Then you have
> a clearly defined point in time you can restore to. But it would be
> convenient to not have to do that. Or another way to think of this is that
> it would be convenient if there was an implicit restore point at the end of
> each backup.
If we were going to solve that problem, that would be the way to do it.
But then we could also solve other similar problems. Like queries that
run for a long time. We could just have them end after a specific time
rather than run to completion and give a correct answer. We could skip
joins that look difficult as well. After all "Run Query" wasn't a very
precise definition of what the user wanted, so what's wrong with a
taking a more relaxed attutude to query execution? They will
appreciate the performance gain, after all.
Precision and doing the safe thing are what people trust us to do.
I recognise this as a common request from users, I just don't think we
should add an option to Postgres to support this when imprecise
recovery is already supported by external means for those that take
the conscious decision to do things that way.
--Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services