Skip site navigation (1) Skip section navigation (2)

Re: Differential backup

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Differential backup
Date: 2010-04-27 18:32:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Apr 27, 2010 at 10:08 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Tue, 2010-04-27 at 08:59 -0500, Kevin Grittner wrote:
>> > An explicit mechanism where Postgres could authoritatively say
>> > which files have changed would make many feel safer, especially
>> > when other databases also do this.
>> Why?  I must be missing something, because my feeling is that if you
>> can't trust your OS to cover something like this, how can you trust
>> any application *running* under that OS to do it?
> Good questions. I'm exploring a perceived need.
> I don't think people want this because they think the OS is flaky. It's
> more about trusting all of the configurations of all of the filesystems
> in use. An explicit mechanism would be more verifiably accurate. It
> might just be about control and blame.

What I think would be cool, though it's not what you proposed, is an
integrated base backup feature.  Say your SR slave gets too far behind
and can't catch up for some reason (the system administrator
accidentally nuked the archive, or you were living on the edge and not
keeping one).  It would be neat to have a way, either manually or
maybe even automatically, to tell the slave, hey, go make a new base
backup.  And it would connect to the master and do pg_start_backup()
and stream down the whole database contents and do pg_stop_backup().
Of course you can do all of this with scripts, but ISTM an integrated
capability would be much easier to administer and might offer some
interesting opportunities for compression.

With respect to what you actually proposed, like Kevin, I'm not sure
what it's good for.  It might make sense if we know what the use case
is but the value certainly isn't obvious.


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-04-27 18:53:16
Subject: Re: testing HS/SR - 1 vs 2 performance
Previous:From: Tom LaneDate: 2010-04-27 18:16:18
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group