Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X5e1G-0002FW-UL for pgsql-admin@arkaria.postgresql.org; Fri, 11 Jul 2014 16:49:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1X5e1F-0002ef-QX for pgsql-admin@arkaria.postgresql.org; Fri, 11 Jul 2014 16:49:57 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1X5e1E-0002eY-Hl for pgsql-admin@postgresql.org; Fri, 11 Jul 2014 16:49:56 +0000 Received: from mail-yh0-x22d.google.com ([2607:f8b0:4002:c01::22d]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1X5e1B-0003pF-Gc for pgsql-admin@postgresql.org; Fri, 11 Jul 2014 16:49:54 +0000 Received: by mail-yh0-f45.google.com with SMTP id t59so513684yho.18 for ; Fri, 11 Jul 2014 09:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=WwaZAWXfYxDLWCtZ/kC8060jR/Qg9hHRwlbrF/H1ofA=; b=EyzUB61N9giq7q3sIxcS8qGp1eplpkcGsqRh3Y+k64fid6+2tAG59tU9k97szd68WG wdUt44X4VGuZu0B9yUtLOBBoLxErMmknR/l69l9xnIMV5j9LsvEZWrMCAY8Kzq9EnGG2 7Sn3Xb7hlPEqcIB3rM5v6EB32hcKeGhWAVRdMDwnHIQH+1ireNOekk/kgE9u+U2mS0OO tPa7UfTK4HkHBQHza91XWDSK7FMOnnOjJ6kjE83/dX381cWRK4Wf1MBkCqn8oWRJtv0A J4X6NpsNwcfTLhBpMiSlmlqenEWyGkQ6GcO+zVj9csLqYZLXnNZd9OBwIUFV/6FQDwel WWlQ== X-Received: by 10.236.201.226 with SMTP id b62mr168254yho.56.1405097392743; Fri, 11 Jul 2014 09:49:52 -0700 (PDT) Received: from [192.168.254.5] (h77.89.102.166.static.ip.windstream.net. [166.102.89.77]) by mx.google.com with ESMTPSA id h34sm6017420yha.50.2014.07.11.09.49.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 09:49:52 -0700 (PDT) Message-ID: <53C015AA.5070908@gmail.com> Date: Fri, 11 Jul 2014 12:49:46 -0400 From: John Scalia User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "pgsql-admin@postgresql.org" Subject: WAL segment management on a standby Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Again, thanks to all to have assisted me with getting the WAL segments to both my standby servers. Everything with that is now working quite well. I do have a related followup question, however. On these standby's nothing is built in to manage those WAL segments in the archive directory. Thus, that directory can grow to the point where it fills up the disk rather quickly. Any good strategies for dealing with the WAL segments that get put in there. Do I really need them after postgresql has copied them up into the pg_xlog directory? If so, how far back should I keep them? Yes, I know about keeping everything between backups. So, if my directory looks like: 00000000300000000C000000A1 00000000300000000C000000A2 00000000300000000C000000A3 00000000300000000C000000A3.backup 00000000300000000C000000A4 Could I safely delete the *A1, *A2, and maybe even the *A3 files? -- Jay -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin