Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1luIzX-0006tV-Sp for pgsql-performance@arkaria.postgresql.org; Fri, 18 Jun 2021 18:13:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1luIzW-0001Pw-T2 for pgsql-performance@arkaria.postgresql.org; Fri, 18 Jun 2021 18:13:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1luIzW-0001Po-Kq for pgsql-performance@lists.postgresql.org; Fri, 18 Jun 2021 18:13:18 +0000 Received: from aws.mailpen.com ([52.43.43.172] helo=aws2.mailpen.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1luIzT-0008Ik-OD for pgsql-performance@lists.postgresql.org; Fri, 18 Jun 2021 18:13:17 +0000 Received: from [172.20.70.208] (unknown [50.35.114.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by aws2.mailpen.com (Postfix) with ESMTPSA id 7B49EC54C3B for ; Fri, 18 Jun 2021 11:13:14 -0700 (PDT) Subject: Re: Estimating wal_keep_size To: pgsql-performance@lists.postgresql.org References: <471a6e7d-928e-c899-bf9f-341ae79b04ea@mailpen.com> <20210617010222.lho6zrgnkkkqyyxp@nol> From: "Dean Gibson (DB Administrator)" Organization: UltiMeth Systems Message-ID: <0df7b2f6-411a-6d9b-873d-6150fcfcc2f4@mailpen.com> Date: Fri, 18 Jun 2021 11:13:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210617010222.lho6zrgnkkkqyyxp@nol> Content-Type: multipart/alternative; boundary="------------EFFF8B1AC88E69DAA3BF9232" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------EFFF8B1AC88E69DAA3BF9232 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2021-06-16 18:02, Julien Rouhaud wrote: > On Wed, Jun 16, 2021 at 05:36:24PM -0700, Dean Gibson (DB Administrator) wrote: >> Is this reasonable thinking? >> >> I'd think that one would want a *wal_keep_size* to cover the pending updates while the standby server might be unavailable, however long one might anticipate that would be. > It's usually a better approach to use a replication slot, to keep all the required WAL files, and only when needed. See https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION-SLOTS for more details. > > Note that a replication slot will keep all WAL files, which might eventually lead to an outage if the standby doesn't come back before the filesystem containing the logs get full. You can cap the maximum amount of retained WAL files since pg 13 using max_slot_wal_keep_size, see > https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE. Granted, but the same question arises about the value for max_slot_wal_keep_size.  Setting either too low risks data loss, & setting either too high results in unnecessary disk space used.  The question was, is the estimated VALUE reasonable under the circumstances? --------------EFFF8B1AC88E69DAA3BF9232 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2021-06-16 18:02, Julien Rouhaud wrote:
On Wed, Jun 16, 2021 at 05:36:24PM -0700, Dean Gibson (DB Administrator) wrote:
Is this reasonable thinking?

I'd think that one would want a *wal_keep_size* to cover the pending updates while the standby server might be unavailable, however long one might anticipate that would be.
It's usually a better approach to use a replication slot, to keep all the required WAL files, and only when needed.  See https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION-SLOTS for more details.

Note that a replication slot will keep all WAL files, which might eventually lead to an outage if the standby doesn't come back before the filesystem containing the logs get full.  You can cap the maximum amount of retained WAL files since pg 13 using max_slot_wal_keep_size, see
https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE.

Granted, but the same question arises about the value for max_slot_wal_keep_size.  Setting either too low risks data loss, & setting either too high results in unnecessary disk space used.  The question was, is the estimated VALUE reasonable under the circumstances?
--------------EFFF8B1AC88E69DAA3BF9232--