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 <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1jxSdQ-0003me-So
	for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Jul 2020 10:03:00 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1jxSdP-00040S-Pg
	for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Jul 2020 10:02:59 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <masao.fujii@oss.nttdata.com>)
	id 1jxSdP-00040L-If
	for pgsql-hackers@lists.postgresql.org; Mon, 20 Jul 2020 10:02:59 +0000
Received: from oss.nttdata.com ([49.212.34.109])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <masao.fujii@oss.nttdata.com>)
	id 1jxSdM-0003AW-KR
	for pgsql-hackers@postgresql.org; Mon, 20 Jul 2020 10:02:59 +0000
Received: from hnk.local (p2360113-ipbf2222funabasi.chiba.ocn.ne.jp
 [114.177.58.113])
	by oss.nttdata.com (Postfix) with ESMTPSA id 2D88E605CC;
	Mon, 20 Jul 2020 19:02:51 +0900 (JST)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com
Subject: Re: max_slot_wal_keep_size and wal_keep_segments
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: David Steele <david@pgmasters.net>,
 Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: alvherre@2ndquadrant.com, pgsql-hackers@postgresql.org
References: <6e4f9605-97f3-7eba-f989-4ae41d637d2f@oss.nttdata.com>
 <20200709.134743.1136524996274963021.horikyota.ntt@gmail.com>
 <866c681c-3082-7010-cc9e-bf3b9483c991@oss.nttdata.com>
 <20200713.160111.1304073320526166244.horikyota.ntt@gmail.com>
 <d8d60d1a-5233-cbcc-099d-ee34033ea619@oss.nttdata.com>
 <87269252-772e-2daf-9955-674a24e24de6@pgmasters.net>
 <efffe8f2-63ea-fe8c-68db-244aa27a63ef@oss.nttdata.com>
 <6479e9a4-0a9d-0772-0401-2c5d0de03ea7@pgmasters.net>
 <dc4768f2-1eff-d2fc-35ba-6b2985b7cb6c@oss.nttdata.com>
Message-ID: <6ff0e503-8bd6-e70f-87bf-fb8389d61f5c@oss.nttdata.com>
Date: Mon, 20 Jul 2020 19:02:50 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <dc4768f2-1eff-d2fc-35ba-6b2985b7cb6c@oss.nttdata.com>
Content-Type: multipart/mixed;
 boundary="------------39F4812AF38B856ADD180515"
Content-Language: en-US
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

This is a multi-part message in MIME format.
--------------39F4812AF38B856ADD180515
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 2020/07/20 13:48, Fujii Masao wrote:
> 
> 
> On 2020/07/17 20:24, David Steele wrote:
>>
>> On 7/17/20 5:11 AM, Fujii Masao wrote:
>>>
>>>
>>> On 2020/07/14 20:30, David Steele wrote:
>>>> On 7/14/20 12:00 AM, Fujii Masao wrote:
>>>>>
>>>>> The patch was no longer applied cleanly because of recent commit.
>>>>> So I updated the patch. Attached.
>>>>>
>>>>> Barring any objection, I will commit this patch.
>>>>
>>>> This doesn't look right:
>>>>
>>>> +   the <xref linkend="guc-wal-keep-size"/> most recent megabytes
>>>> +   WAL files plus one WAL file are
>>>>
>>>> How about:
>>>>
>>>> +   <xref linkend="guc-wal-keep-size"/> megabytes of
>>>> +   WAL files plus one WAL file are
>>>
>>> Thanks for the comment! Isn't it better to keep "most recent" part?
>>> If so, what about either of the followings?
>>>
>>> 1. <xref linkend="guc-wal-keep-size"/> megabytes of WAL files plus
>>>      one WAL file that were most recently generated are kept all time.
>>>
>>> 2. <xref linkend="guc-wal-keep-size"/> megabytes + <xref linkend="guc-wal-segment-size"> bytes
>>>      of WAL files that were most recently generated are kept all time.
>>
>> "most recent" seemed implied to me, but I see your point.
>>
>> How about:
>>
>> +   the most recent <xref linkend="guc-wal-keep-size"/> megabytes of
>> +   WAL files plus one additional WAL file are
> 
> I adopted this and pushed the patch. Thanks!
> 
> Also we need to update the release note for v13. What about adding the following?
> 
> ------------------------------------
> Rename configuration parameter wal_keep_segments to wal_keep_size.
> 
> This allows how much WAL files to retain for the standby server, by bytes instead of the number of files.
> If you previously used wal_keep_segments, the following formula will give you an approximately equivalent setting:
> 
> wal_keep_size = wal_keep_segments * wal_segment_size (typically 16MB)
> ------------------------------------

Patch attached.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

--------------39F4812AF38B856ADD180515
Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0";
 name="wal_keep_size_release_note_v1.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="wal_keep_size_release_note_v1.patch"

ZGlmZiAtLWdpdCBhL2RvYy9zcmMvc2dtbC9yZWxlYXNlLTEzLnNnbWwgYi9kb2Mvc3JjL3Nn
bWwvcmVsZWFzZS0xMy5zZ21sCmluZGV4IDIyMzYzYTE4NmIuLmMzNjk4YzE0MDEgMTAwNjQ0
Ci0tLSBhL2RvYy9zcmMvc2dtbC9yZWxlYXNlLTEzLnNnbWwKKysrIGIvZG9jL3NyYy9zZ21s
L3JlbGVhc2UtMTMuc2dtbApAQCAtMjA5LDYgKzIwOSwyOCBAQCBBdXRob3I6IEZ1amlpIE1h
c2FvIDxmdWppaUBwb3N0Z3Jlc3FsLm9yZz4KIAogICAgIDxsaXN0aXRlbT4KIDwhLS0KK0F1
dGhvcjogRnVqaWkgTWFzYW8gPGZ1amlpQHBvc3RncmVzcWwub3JnPgorMjAyMC0wNy0yMCBb
ZjVkZmY0NTk2Ml0gUmVuYW1lIHdhbF9rZWVwX3NlZ21lbnRzIHRvIHdhbF9rZWVwX3NpemUu
CistLT4KKworICAgICA8cGFyYT4KKyAgICAgIFJlbmFtZSBjb25maWd1cmF0aW9uIHBhcmFt
ZXRlciA8dmFybmFtZT53YWxfa2VlcF9zZWdtZW50czwvdmFybmFtZT4KKyAgICAgIHRvIDx4
cmVmIGxpbmtlbmQ9Imd1Yy13YWwta2VlcC1zaXplIi8+IChGdWppaSBNYXNhbykKKyAgICAg
PC9wYXJhPgorCisgICAgIDxwYXJhPgorICAgICAgVGhpcyBhbGxvd3MgaG93IG11Y2ggV0FM
IGZpbGVzIHRvIHJldGFpbiBmb3IgdGhlIHN0YW5kYnkgc2VydmVyLAorICAgICAgdG8gYmUg
c3BlY2lmaWVkIGJ5IGJ5dGVzIGluc3RlYWQgb2YgdGhlIG51bWJlciBvZiBmaWxlcy4gSWYg
eW91CisgICAgICBwcmV2aW91c2x5IHVzZWQgPHZhcm5hbWU+d2FsX2tlZXBfc2VnbWVudHM8
L3Zhcm5hbWU+LAorICAgICAgdGhlIGZvbGxvd2luZyBmb3JtdWxhIHdpbGwgZ2l2ZSB5b3Ug
YW4gYXBwcm94aW1hdGVseSBlcXVpdmFsZW50IHNldHRpbmc6Cis8cHJvZ3JhbWxpc3Rpbmc+
Cit3YWxfa2VlcF9zaXplID0gd2FsX2tlZXBfc2VnbWVudHMgKiB3YWxfc2VnbWVudF9zaXpl
ICh0eXBpY2FsbHkgMTZNQikKKzwvcHJvZ3JhbWxpc3Rpbmc+CisgICAgIDwvcGFyYT4KKyAg
ICA8L2xpc3RpdGVtPgorCisgICAgPGxpc3RpdGVtPgorPCEtLQogQXV0aG9yOiBUb20gTGFu
ZSA8dGdsQHNzcy5wZ2gucGEudXM+CiAyMDIwLTAzLTA1IFs4NGVjYTE0YmNdIFJlbW92ZSBh
bmNpZW50IGhhY2tzIHRvIGlnbm9yZSBjZXJ0YWluIG9wY2xhc3MgbmFtZXMgaW4KIC0tPgo=
--------------39F4812AF38B856ADD180515--