Re: Synch Rep for CommitFest 2009-07 - Mailing list pgsql-hackers

From Rick Gigger
Subject Re: Synch Rep for CommitFest 2009-07
Date
Msg-id DA346E39-AE5A-4DB3-A3AA-60566DE1978C@alpinenetworking.com
Whole thread Raw
In response to Re: Synch Rep for CommitFest 2009-07  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Synch Rep for CommitFest 2009-07  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Jul 16, 2009, at 12:07 AM, Heikki Linnakangas wrote:

> Dimitri Fontaine wrote:
>> Le 15 juil. 09 à 23:03, Heikki Linnakangas a écrit :
>> Furthermore, the counter-argument against having the primary
>> able to send data from the archives to some standby is that it should
>> still work when primary's dead, but as this is only done in the setup
>> phase, I don't see that being able to continue preparing a not-yet-
>> ready
>> standby against a dead primary is buying us anything.
>
> The situation arises also when the standby falls badly behind. A
> simple
> solution to that is to add a switch in the master to specify "always
> keep X MB of WAL in pg_xlog". The standby will then still find it in
> pg_xlog, making it harder for a standby to fall so much behind that it
> can't find the WAL it needs in the primary anymore. Tom suggested that
> we can just give up and re-sync with a new base backup, but that
> really
> requires built-in base backup capability, and is only practical for
> small databases.

If you use an rsync like algorithm for doing the base backups wouldn't
that increase the size of the database for which it would still be
practical to just re-sync?  Couldn't you in fact sync a very large
database if the amount of actual change in the files was a small
percentage of the total size?

pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [PATCH] DefaultACLs
Next
From: Grzegorz Jaskiewicz
Date:
Subject: Re: boolean in C