On Thu, Oct 7, 2010 at 9:08 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Thu, Oct 7, 2010 at 8:46 PM, Steve Singer <ssin...@ca.afilias.info> wrote: >> Then you have to deal with telling the archive how long it needs to keep WAL >> segments because the master might ask for them back. > > Yeah, it's not easy to determine how long we should keep the archived WAL > files. > We need to calculate which WAL file is deletable according to the progress of > each standby and the state of the stored base backups which still might be > used > for PITR. > >> If the archive is >> remote from the master then you have some extra network copying going on. > > Yep, so I think that the master (i.e., walsender) should read the archived > WAL file by using restore_command specified by users. If the archive is > remote from the master, then we would need to specify something like scp in > restore_command. Also, even if you compress the archived WAL file by using > pg_compress, the master can decompress it by using pg_decompress in > restore_command and transfer it. > >> It would be better to let the slave being reconfigured to read the missing >> WAL from the archive. > > That's one of choices. > > But I've heard that some people don't want to set up the shared archive area > which can be accessed by the master and the standby. For example, they feel > that it's complex to configure NFS server or automatic-scp-without-password > setting for sharing the archived WAL files. > > Currently we have to increase wal_keep_segments to work around that problem. > But the pg_xlog disk space is usually small and not suitable to keep many > WAL files. So we might be unable to increase wal_keep_segments. > > If we allow the master to stream WAL files from the archive, we don't need > to increase wal_keep_segments and set up such a complex configuration. So > this idea is one of useful choices, I think.
I'm not sure anyone other than yourself has endorsed this idea, but in any case it seems off the critical path for getting this feature committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
