On Fri, Dec 18, 2009 at 12:22 PM, Florian Pflug <fgp.phlo.org@gmail.com> wrote:
> On 18.12.09 17:05 , Robert Haas wrote:
>>
>> On Fri, Dec 18, 2009 at 11:03 AM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>
>>> Or some way for to register the standby with the master so that
>>> the master knows it's out there, and still needs the logs, even when
>>> it's not connected.
>>
>> That is the real answer, I think.
>
> It'd prefer if the slave could automatically fetch a new base backup if it
> falls behind too far to catch up with the available logs. That way, old logs
> don't start piling up on the server if a slave goes offline for a long time.
>
> The slave could for example run a configurable shell script in that case,
> for example. You could then use that to rsync the data directory from the
> server (after a pg_start_backup() of course).
That would be nice to have too, but it's almost certainly much harder
to implement. In particular, there's no hard and fast rule for
figuring out when you've dropped so far behind that resnapping the
whole thing is faster than replaying the WAL bit by bit. And, of
course, you'll have to take the standby down if you go that route,
whereas trying to catch up the WAL lets it stay up throughout the
process.
I think (as I did/do with Hot Standby) that the most important thing
here is to get to a point where we have a reasonably good feature that
is of some use, and commit it. It will probably have some annoying
limitations; we can remove those later. I have a feel that what we
have right now is going to be non-robust in the face of network
breaks, but that is a problem that can be fixed by a future patch.
...Robert
