Re: Feature request: pg_basebackup --force

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Joshua Berkus" <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Feature request: pg_basebackup --force
Date: 2011-04-11 15:03:49
Message-ID: 4DA2D205020000250003C62C@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

> That's exactly what pg_basebackup does. Once you move into more
> complicated scenarios with multiple standbys and WAL archiving,
> it's inevitably going to be more complicated to set up.
>
> That doesn't mean that we can't make it easier - we can and we
> should - but I don't think the common complaint that replication
> is hard to set up is true anymore.

Getting back to the rsync-like behavior, which is what led the
conversation in this direction, I think -- the point of that seemed
to be to allow similar ease of use for those activating a replicated
node as the master, without requiring that the entire data directory
be sent over a slow WAN or Internet path when the delta needed to
modify what was already at the remote end to match the new master
might be orders of magnitude less than data than that.

The intelligence to support that would be a fraction of what is in
rsync. In fact, since we might want to ignore hint bit differences
where possible, rsync might not work nearly as well as a home-grown
solution.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-04-11 15:16:15 Re: SSI bug?
Previous Message john.cheng 2011-04-11 14:35:21 how to keep/lock/ hide pg_hba.conf ?