Re: [9.3 bug] disk space in pg_xlog increases during archive recovery

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