On 7 May 2013 13:50, Heikki Linnakangas 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 part of the wide
On Tue, May 7, 2013 at 9:38 PM, Simon Riggs wrote:
> On 3 May 2013 14:40, Heikki Linnakangas 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
On 07.05.2013 15:38, Simon Riggs wrote:
On 3 May 2013 14:40, Heikki Linnakangas 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 consisten
On 3 May 2013 14:40, Heikki Linnakangas 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 softw
On Fri, May 3, 2013 at 11:13 AM, Cédric Villemain
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 there
>>
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
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 brea
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"
> > >
Le vendredi 3 mai 2013 02:54:15, Michael Paquier a écrit :
> On Fri, May 3, 2013 at 8:56 AM, Bruce Momjian 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 fair
On Fri, May 3, 2013 at 8:56 AM, Bruce Momjian 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 help - some o
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 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 c
On 2 May 2013 08:31, Magnus Hagander 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 and recovery_targe
On Thu, May 2, 2013 at 8:55 AM, Simon Riggs wrote:
> On 26 April 2013 18:13, Heikki Linnakangas wrote:
>> On 26.04.2013 19:50, Magnus Hagander wrote:
>>>
>>> On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggs
>>> wrote:
On 26 April 2013 17:25, Heikki Linnakangas
wrote:
>
> Actual
On 26 April 2013 18:13, Heikki Linnakangas wrote:
> On 26.04.2013 19:50, Magnus Hagander wrote:
>>
>> On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggs
>> wrote:
>>>
>>> On 26 April 2013 17:25, Heikki Linnakangas
>>> wrote:
Actually, from a usability point of view I think would be nice to hav
On Thu, May 2, 2013 at 7:40 AM, Bruce Momjian wrote:
> On Fri, Apr 26, 2013 at 09:48:48AM -0400, Tom Lane wrote:
> > Magnus Hagander 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
> > > sim
On Fri, Apr 26, 2013 at 09:48:48AM -0400, Tom Lane wrote:
> Magnus Hagander 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
On 26.04.2013 19:50, Magnus Hagander wrote:
On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggs wrote:
On 26 April 2013 17:25, Heikki Linnakangas wrote:
Actually, from a usability point of view I think would be nice to have just
one setting, "recovery_target". It's already somewhat confusing to have
On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggs wrote:
> On 26 April 2013 17:25, Heikki Linnakangas wrote:
>> On 26.04.2013 19:05, Simon Riggs wrote:
>>>
>>> On 26 April 2013 16:38, Robert Haas wrote:
On Fri, Apr 26, 2013 at 11:35 AM, Simon Riggs
wrote:
>
> Given that I was d
On 26 April 2013 17:25, Heikki Linnakangas wrote:
> On 26.04.2013 19:05, Simon Riggs wrote:
>>
>> On 26 April 2013 16:38, Robert Haas wrote:
>>>
>>> On Fri, Apr 26, 2013 at 11:35 AM, Simon Riggs
>>> wrote:
Given that I was describing how we might implement Heikki's
suggestion, I fi
On Fri, Apr 26, 2013 at 12:25 PM, Heikki Linnakangas
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.
> Actually, from a usabi
On 26.04.2013 19:05, Simon Riggs wrote:
On 26 April 2013 16:38, Robert Haas wrote:
On Fri, Apr 26, 2013 at 11:35 AM, Simon Riggs 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 ha
On 26 April 2013 16:38, Robert Haas wrote:
> On Fri, Apr 26, 2013 at 11:35 AM, Simon Riggs 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
On Fri, Apr 26, 2013 at 11:35 AM, Simon Riggs 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 server already knows
On 26 April 2013 15:38, Robert Haas wrote:
> On Fri, Apr 26, 2013 at 10:05 AM, Simon Riggs 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
On Apr 26, 2013 4:38 PM, "Robert Haas" wrote:
>
> On Fri, Apr 26, 2013 at 10:05 AM, Simon Riggs
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 ju
On Fri, Apr 26, 2013 at 10:05 AM, Simon Riggs 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 found so frighte
On 26 April 2013 14:48, Tom Lane wrote:
> Magnus Hagander 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 t
Magnus Hagander 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, but also much
>
On 26.04.2013 14:54, Magnus Hagander wrote:
On Fri, Apr 26, 2013 at 1:47 PM, Simon Riggs wrote:
On 26 April 2013 11:29, Heikki Linnakangas 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 Pos
On 26 April 2013 12:54, Magnus Hagander 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 backup slightly
On Fri, Apr 26, 2013 at 1:47 PM, Simon Riggs wrote:
> On 26 April 2013 11:29, Heikki Linnakangas 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 tha
On 26 April 2013 11:29, Heikki Linnakangas 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 mos
On 26.04.2013 12:16, Simon Riggs wrote:
On 18 April 2013 19:11, Heikki Linnakangas 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
On 18 April 2013 19:11, Heikki Linnakangas 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 need, if we think more
On Fri, Apr 19, 2013 at 3:11 AM, Heikki Linnakangas 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, PostgreSQL will recove
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
On Fri, Apr 19, 2013 at 8:30 AM, Robert Haas wrote:
> On Thu, Apr 18, 2013 at 2:11 PM, Heikki Linnakangas
> wrote:
>>
>> It seems that we're missing a setting, something like recovery_target =
>> 'immediate', which would mean "stop as soon as consistency is reached". Or
>> am I missing some trick
On Fri, Apr 19, 2013 at 10:30 PM, Robert Haas wrote:
> On Thu, Apr 18, 2013 at 2:11 PM, Heikki Linnakangas
> 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.
>>
On Thu, Apr 18, 2013 at 2:11 PM, Heikki Linnakangas
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, PostgreSQL will recover
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 poin
41 matches
Mail list logo
