Postgres Pro
Downloads
Home   >   mailing lists

Re: [9.3 bug] disk space in pg_xlog increases during archive recovery - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [9.3 bug] disk space in pg_xlog increases during archive recovery
Date
Msg-id CAB7nPqQOacfMxDrN+Fpy0h+WjmuiQGAuN7aGHAqPZcuVjvuOwg@mail.gmail.com
Whole thread Raw
In response to Re: [9.3 bug] disk space in pg_xlog increases during archive recovery  ("MauMau" <maumau307@gmail.com>)
Responses Re: [9.3 bug] disk space in pg_xlog increases during archive recovery  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: [9.3 bug] disk space in pg_xlog increases during archive recovery  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Tree view



On Fri, Aug 2, 2013 at 12:24 AM, MauMau <maumau307@gmail.com> wrote:
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.
You are right about that, you should stick with the core features as much as you can and limit the use of wrapper utilities. Since 9.1 and the apparition of a built-in standby mode inside Postgres (with the apparition of the GUC parameter hot_standby), it seems better to use that instead of pg_standby, which would likely (personal opinion, feel free to scream at me) be removed in a future release.
 


 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.
By reading this thread, -1 for the addition of a new GUC parameter related to cascading, it looks like an overkill for the possible gain. And +1 for the removal of WAL file once it is replayed in archive recovery if cascading replication is not allowed. However, what about wal_keep_segments? Doesn't the server keep segments even if replication is not allowed? If yes, the immediate WAL file drop after replay needs to take care of that...
--
Michael

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Next
From: Andres Freund
Date:
Subject: Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])