On Thu, Oct 7, 2010 at 9:08 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, Oct 7, 2010 at 8:46 PM, Steve Singer <ssinger@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