Hi, Heiki-san,
From: MauMau maumau...@gmail.com
From: Heikki Linnakangas hlinnakan...@vmware.com
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
On 01/24/2014 01:37 PM, MauMau wrote:
Hi, Heiki-san,
From: MauMau maumau...@gmail.com
From: Heikki Linnakangas hlinnakan...@vmware.com
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
On Sat, Jan 25, 2014 at 5:10 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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:
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
From: Michael Paquier michael.paqu...@gmail.com
On Fri, Jan 10, 2014 at 12:08 AM, MauMau maumau...@gmail.com 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.
On 12/09/2013 03:05 PM, MauMau wrote:
From: Heikki Linnakangas hlinnakan...@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
From: Heikki Linnakangas hlinnakan...@vmware.com
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
On Fri, Jan 10, 2014 at 12:08 AM, MauMau maumau...@gmail.com 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
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
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
From: Heikki Linnakangas hlinnakan...@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
From: Michael Paquier michael.paqu...@gmail.com
On Sat, Dec 7, 2013 at 9:06 AM, MauMau maumau...@gmail.com 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
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
On Sat, Dec 7, 2013 at 9:06 AM, MauMau maumau...@gmail.com 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
14 matches
Mail list logo
