From: "Fujii Masao" <masao.fujii@gmail.com>
>> However, isn't StandbyRequested true (= standby_mode set to on) to enable
>> warm standby?
>
> We can set up warm-standby by using pg_standby even if standby_mode = off.
I see. However, I understand that pg_standby is a legacy feature, and the
current way to setup a warm standby is to set standby=on and restore_command
in recovery.conf. So I think it might not be necessary to support cascading
replication with pg_standby, if supporting it would prevent better
implementation of new features.
>> I'm afraid people set max_wal_senders>0 and hot_standby=on
>> even on the primary server to make the contents of postgresql.conf
>> identical
>> on both the primary and the standby for easier configuration. If so,
>> normal
>> archive recovery (PITR, not the standby recovery) would face the original
>> problem -- unnecessary WAL accumulation in pg_xlog/. So I'm wonder if
>> AllowCascadeReplication() is enough.
>
> One idea is to add new GUC parameter like enable_cascade_replication
> and then prevent WAL file from being kept in pg_xlog if that parameter is
> off.
> But we cannot apply such change into the already-released version 9.2.
Yes, I thought the same, too. Adding a new GUC to enable cascading
replication now would be a usability degradation. But I have no idea of any
better way. It seems we need to take either v1 or v2 of the patch I sent.
If we consider that we don't have to support cascading replication for a
legacy pg_standby, v1 patch is definitely better because the standby server
would not keep restored archive WAL in pg_xlog when cascading replication is
not used. Otherwise, we have to take v2 patch.
Could you choose either and commit it?
Regards
MauMau