On Sat, Jan 25, 2014 at 5:10 AM, Heikki Linnakangas
wrote:
> Thanks, committed!
It seems that this patch has not been pushed :)
Regards,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgs
On 01/24/2014 01:37 PM, MauMau wrote:
Hi, Heiki-san,
From: "MauMau"
From: "Heikki Linnakangas"
After some refactoring and fixing bugs in the existing code, I came up
with the attached patch. I called the option simply "recovery_target",
with the only allowed value of "immediate". IOW, if you
Hi, Heiki-san,
From: "MauMau"
From: "Heikki Linnakangas"
After some refactoring and fixing bugs in the existing code, I came up
with the attached patch. I called the option simply "recovery_target",
with the only allowed value of "immediate". IOW, if you want to stop
recovery as early as poss
From: "Michael Paquier"
On Fri, Jan 10, 2014 at 12:08 AM, MauMau wrote:
C2. "recovery_target = 'immediate'" sounds less intuitive than my
suggestion
"recovery_target_time = 'backup_point'", at least for those who want to
recover to the backup point.
Although I don't have a good naming sense i
The documentation doesn't build.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 10, 2014 at 12:08 AM, MauMau wrote:
> C2. "recovery_target = 'immediate'" sounds less intuitive than my suggestion
> "recovery_target_time = 'backup_point'", at least for those who want to
> recover to the backup point.
> Although I don't have a good naming sense in English, the value
From: "Heikki Linnakangas"
After some refactoring and fixing bugs in the existing code, I came up
with the attached patch. I called the option simply "recovery_target",
with the only allowed value of "immediate". IOW, if you want to stop
recovery as early as possible, you add recovery_target='im
On 12/09/2013 03:05 PM, MauMau wrote:
From: "Heikki Linnakangas"
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
From: "Heikki Linnakangas"
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
On 12/09/2013 02:03 PM, MauMau wrote:
From: "Michael Paquier"
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
From: "Michael Paquier"
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
From: "Michael Paquier"
On Sat, Dec 7, 2013 at 9:06 AM, MauMau wrote:
Recovery target 'immediate'
http://www.postgresql.org/message-id/51703751.2020...@vmware.com
May I implement this feature and submit a patch for the next commitfest
if I have time?
Please feel free. I might as well partic
On Sat, Dec 7, 2013 at 9:06 AM, MauMau wrote:
> It seems that Everyone welcomed the following functionality, and I also want
> it to solve some problem. But this doesn't appear to be undertaken.
Indeed, nobody has really showed up to implement that.
>
> Recovery target 'immediate'
> http://www.p
Hello,
It seems that Everyone welcomed the following functionality, and I also want
it to solve some problem. But this doesn't appear to be undertaken.
Recovery target 'immediate'
http://www.postgresql.org/message-id/51703751.2020...@vmware.com
Is there any technical difficulty? May I imple
14 matches
Mail list logo
