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 <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org