Re: [RFC] Incremental backup v2: add backup profile to base backup

From: David Fetter <david(at)fetter(dot)org>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Gabriele Bartolini <gabriele(dot)bartolini(at)2ndquadrant(dot)it>, Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] Incremental backup v2: add backup profile to base backup
Date: 2014-10-06 22:55:47
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Mon, Oct 06, 2014 at 07:24:32PM +0300, Heikki Linnakangas wrote:
> On 10/06/2014 07:00 PM, Gabriele Bartolini wrote:
> >Hello,
> >
> >2014-10-06 17:51 GMT+02:00 Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it
> >>:
> >
> >>I agree that a full backup does not need to include a profile.
> >>
> >>I've added the option to require the profile even for a full backup, as
> >>it can be useful for backup softwares. We could remove the option and
> >>build the profile only during incremental backups, if required. However,
> >>I would avoid the needing to scan the whole backup to know the size of
> >>the recovered data directory, hence the backup profile.
> >
> >I really like this approach.
> >
> >I think we should leave users the ability to ship a profile file even in
> >case of full backup (by default disabled).
> I don't see the point of making the profile optional. Why burden the user
> with that decision? I'm not convinced we need it at all, but if we're going
> to have a profile file, it should always be included.

+1 for fewer user decisions, especially with something light-weight in
resource consumption like the profile.

David Fetter <david(at)fetter(dot)org>
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://

Remember to vote!
Consider donating to Postgres:

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2014-10-06 23:03:33 Re: replicating DROP commands across servers
Previous Message Alvaro Herrera 2014-10-06 22:33:59 Re: BRIN indexes - TRAP: BadArgument