On 3 May 2013 14:40, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 03.05.2013 16:29, Bruce Momjian wrote:
On Fri, May 3, 2013 at 01:02:08PM +0200, Cédric Villemain wrote:
This changes the existing API which will confuse people that know it
and invalidate everything written in
On 07.05.2013 15:38, Simon Riggs wrote:
On 3 May 2013 14:40, Heikki Linnakangashlinnakan...@vmware.com wrote:
If we want to avoid adding a new option for this, how about a magic restore
point called consistent or immediate:
recovery_target_name='immediate'
That would stop recovery right
On Tue, May 7, 2013 at 9:38 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 3 May 2013 14:40, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 03.05.2013 16:29, Bruce Momjian wrote:
On Fri, May 3, 2013 at 01:02:08PM +0200, Cédric Villemain wrote:
This changes the existing API which will
On 7 May 2013 13:50, Heikki Linnakangas hlinnakan...@vmware.com wrote:
Can I suggest that we discuss a range of related changes together? So
we have a roadmap of agreed changes in this area. That will be more
efficient than discussing each one individually; often each one makes
sense only as
On Fri, May 3, 2013 at 11:13 AM, Cédric Villemain
ced...@2ndquadrant.com wrote:
If we want to avoid adding a new option for this, how about a magic
restore point called consistent or immediate:
recovery_target_name='immediate'
That would stop recovery right after reaching consistency, but
Le vendredi 3 mai 2013 02:54:15, Michael Paquier a écrit :
On Fri, May 3, 2013 at 8:56 AM, Bruce Momjian br...@momjian.us wrote:
On Thu, May 2, 2013 at 09:31:03AM +0200, Magnus Hagander wrote:
Actually, there is - I hear it quite often from people not so
experienced in PostgreSQL. Though
On Fri, May 3, 2013 at 01:02:08PM +0200, Cédric Villemain wrote:
This changes the existing API which will confuse people that know it
and invalidate everything written in software and on wikis as to how
to do it. That means all the in case of fire break glass
instructions are
On 03.05.2013 16:29, Bruce Momjian wrote:
On Fri, May 3, 2013 at 01:02:08PM +0200, Cédric Villemain wrote:
This changes the existing API which will confuse people that know it
and invalidate everything written in software and on wikis as to how
to do it. That means all the in case of fire
Le vendredi 3 mai 2013 15:40:51, Heikki Linnakangas a écrit :
On 03.05.2013 16:29, Bruce Momjian wrote:
On Fri, May 3, 2013 at 01:02:08PM +0200, Cédric Villemain wrote:
This changes the existing API which will confuse people that know it
and invalidate everything written in software and on
On 26 April 2013 18:13, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 26.04.2013 19:50, Magnus Hagander wrote:
On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggssi...@2ndquadrant.com
wrote:
On 26 April 2013 17:25, Heikki Linnakangashlinnakan...@vmware.com
wrote:
Actually, from a
On Thu, May 2, 2013 at 8:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 26 April 2013 18:13, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 26.04.2013 19:50, Magnus Hagander wrote:
On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggssi...@2ndquadrant.com
wrote:
On 26 April 2013 17:25,
On 2 May 2013 08:31, Magnus Hagander mag...@hagander.net wrote:
That said, there is one property that's very unclear now and that's
that you can only set one of recovery_target_time, recovery_target_xid
and recovery_target_name. But they can be freely combined with
recovery_target_timeline
On Thu, May 2, 2013 at 09:04:20AM +0100, Simon Riggs wrote:
If we feel strongly about user interface design problems we should
treat them the same way we treat performance issues. Profile to
identify problem areas, analyze problems in those areas and suggest
solutions, then make tests to
On Thu, May 2, 2013 at 09:31:03AM +0200, Magnus Hagander wrote:
Actually, there is - I hear it quite often from people not so
experienced in PostgreSQL. Though in fairness, I'm not entirely sure
the new syntax would help - some of those need a tool to do it for
them, really (and such tools
On Fri, May 3, 2013 at 8:56 AM, Bruce Momjian br...@momjian.us wrote:
On Thu, May 2, 2013 at 09:31:03AM +0200, Magnus Hagander wrote:
Actually, there is - I hear it quite often from people not so
experienced in PostgreSQL. Though in fairness, I'm not entirely sure
the new syntax would
On Fri, Apr 26, 2013 at 09:48:48AM -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
That said, maybe the easier choice for a *system* (such as v-thingy)
would be to simply to the full backup using pg_basebackup -x (or
similar), therefor not needing the log archive at all
On Thu, May 2, 2013 at 7:40 AM, Bruce Momjian br...@momjian.us wrote:
On Fri, Apr 26, 2013 at 09:48:48AM -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
That said, maybe the easier choice for a *system* (such as v-thingy)
would be to simply to the full backup using
On 18 April 2013 19:11, Heikki Linnakangas hlinnakan...@vmware.com wrote:
I just found out that if you use continuous archiving and online backups,
it's surprisingly difficult to restore a backup, without replaying any more
WAL than necessary.
I didn't add it myself because I don't see the
On 26.04.2013 12:16, Simon Riggs wrote:
On 18 April 2013 19:11, Heikki Linnakangashlinnakan...@vmware.com wrote:
I just found out that if you use continuous archiving and online backups,
it's surprisingly difficult to restore a backup, without replaying any more
WAL than necessary.
I didn't
On 26 April 2013 11:29, Heikki Linnakangas hlinnakan...@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
On Fri, Apr 26, 2013 at 1:47 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 26 April 2013 11:29, Heikki Linnakangas hlinnakan...@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
On 26 April 2013 12:54, Magnus Hagander mag...@hagander.net wrote:
That said, maybe the easier choice for a *system* (such as v-thingy)
would be to simply to the full backup using pg_basebackup -x (or
similar), therefor not needing the log archive at all when restoring.
Yes, it makes the base
On 26.04.2013 14:54, Magnus Hagander wrote:
On Fri, Apr 26, 2013 at 1:47 PM, Simon Riggssi...@2ndquadrant.com wrote:
On 26 April 2013 11:29, Heikki Linnakangashlinnakan...@vmware.com wrote:
But there is also an operation to simply restore a backup.
Just because a tool supports an
Magnus Hagander mag...@hagander.net writes:
That said, maybe the easier choice for a *system* (such as v-thingy)
would be to simply to the full backup using pg_basebackup -x (or
similar), therefor not needing the log archive at all when restoring.
Yes, it makes the base backup slightly larger,
On 26 April 2013 14:48, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
That said, maybe the easier choice for a *system* (such as v-thingy)
would be to simply to the full backup using pg_basebackup -x (or
similar), therefor not needing the log archive at all
On Fri, Apr 26, 2013 at 10:05 AM, Simon Riggs si...@2ndquadrant.com wrote:
Restore points are definitely the way to go here, this is what they
were created for. Stopping at a labelled location has a defined
meaning for the user, which is much better than just stop anywhere
convenient, which I
On Apr 26, 2013 4:38 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 26, 2013 at 10:05 AM, Simon Riggs si...@2ndquadrant.com
wrote:
Restore points are definitely the way to go here, this is what they
were created for. Stopping at a labelled location has a defined
meaning for the
On 26 April 2013 15:38, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 26, 2013 at 10:05 AM, Simon Riggs si...@2ndquadrant.com wrote:
Restore points are definitely the way to go here, this is what they
were created for. Stopping at a labelled location has a defined
meaning for the user,
On Fri, Apr 26, 2013 at 11:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
Given that I was describing how we might implement Heikki's
suggestion, I find this comment confusing.
Please explain.
Heikki's suggestion is simply to have a mode that stops as soon as
consistency is reached. The
On 26 April 2013 16:38, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 26, 2013 at 11:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
Given that I was describing how we might implement Heikki's
suggestion, I find this comment confusing.
Please explain.
Heikki's suggestion is simply to
On 26.04.2013 19:05, Simon Riggs wrote:
On 26 April 2013 16:38, Robert Haasrobertmh...@gmail.com wrote:
On Fri, Apr 26, 2013 at 11:35 AM, Simon Riggssi...@2ndquadrant.com wrote:
Given that I was describing how we might implement Heikki's
suggestion, I find this comment confusing.
Please
On Fri, Apr 26, 2013 at 12:25 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Doing it the other way means you need to add a new kind of recovery
target to the API just for this.
recovery_target_immediate = on
Sounds good to me.
Yeah, I don't have a problem with that, at all.
On 26 April 2013 17:25, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 26.04.2013 19:05, Simon Riggs wrote:
On 26 April 2013 16:38, Robert Haasrobertmh...@gmail.com wrote:
On Fri, Apr 26, 2013 at 11:35 AM, Simon Riggssi...@2ndquadrant.com
wrote:
Given that I was describing how we
On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 26 April 2013 17:25, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 26.04.2013 19:05, Simon Riggs wrote:
On 26 April 2013 16:38, Robert Haasrobertmh...@gmail.com wrote:
On Fri, Apr 26, 2013 at 11:35 AM, Simon
On 26.04.2013 19:50, Magnus Hagander wrote:
On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggssi...@2ndquadrant.com wrote:
On 26 April 2013 17:25, Heikki Linnakangashlinnakan...@vmware.com wrote:
Actually, from a usability point of view I think would be nice to have just
one setting,
On Fri, Apr 19, 2013 at 10:30 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Apr 18, 2013 at 2:11 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I just found out that if you use continuous archiving and online backups,
it's surprisingly difficult to restore a backup, without
On Fri, Apr 19, 2013 at 8:30 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Apr 18, 2013 at 2:11 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
It seems that we're missing a setting, something like recovery_target =
'immediate', which would mean stop as soon as consistency is
On Thu, Apr 18, 2013 at 10:11 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I just found out that if you use continuous archiving and online backups,
it's surprisingly difficult to restore a backup, without replaying any more
WAL than necessary.
You can find first WAL file name in
On Fri, Apr 19, 2013 at 3:11 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
I just found out that if you use continuous archiving and online backups,
it's surprisingly difficult to restore a backup, without replaying any more
WAL than necessary.
If you don't set a recovery target,
On Thu, Apr 18, 2013 at 2:11 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I just found out that if you use continuous archiving and online backups,
it's surprisingly difficult to restore a backup, without replaying any more
WAL than necessary.
If you don't set a recovery target,
I just found out that if you use continuous archiving and online
backups, it's surprisingly difficult to restore a backup, without
replaying any more WAL than necessary.
If you don't set a recovery target, PostgreSQL will recover all the WAL
it finds. You can set recovery target time to a
41 matches
Mail list logo