You obviously did not read further down :-)
I was proposing a subscription system, where the slave can specify the
oldest WAL file it is interested in, and keep that up to date as it
processes them.
That could cause of course trouble if a slave dies and it won't update
the subscription, but that's not any different than the current setup if
the archive_command starts failing constantly because the archive site
is down. In either case human intervention is needed. The DB connection
based approach has the advantage that you don't have to restart the
server if your slave location changes, and you can have multiple slaves
at the same time if you like, e.g. if you want to smoothly move over the
slave to another machine.
Cheers,
Csaba.
On Tue, 2006-02-07 at 16:18, Tom Lane wrote:
> Csaba Nagy <nagy@ecircle-ag.com> writes:
> > The procedure should be something similar to the one available today if
> > you do it manually. The main difference would be that the standby
> > postmaster should connect to the primary server, and get all table data
> > and WAL record stream through normal data base connections...
>
> This is pie-in-the-sky really. A design like that would mean that the
> master could *never* recycle WAL files, because it could never know when
> some slave would pop up demanding a copy of ancient history.
>
> regards, tom lane