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 1jlZLk-0002IC-Tg for pgsql-docs@arkaria.postgresql.org; Wed, 17 Jun 2020 14:47:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZLj-0001VI-LR for pgsql-docs@arkaria.postgresql.org; Wed, 17 Jun 2020 14:47:35 +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 1jlZLj-0001VB-FZ for pgsql-docs@lists.postgresql.org; Wed, 17 Jun 2020 14:47:35 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jlZLg-0003Mv-Qm for pgsql-docs@lists.postgresql.org; Wed, 17 Jun 2020 14:47:34 +0000 Received: from hnk.local (p2604028-ipngn12401funabasi.chiba.ocn.ne.jp [180.1.110.28]) by oss.nttdata.com (Postfix) with ESMTPSA id 588C860524 for ; Wed, 17 Jun 2020 23:47:28 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com To: pgsql-docs@lists.postgresql.org From: Fujii Masao Subject: The description for pg_replication_slots.restart_lsn Message-ID: <6497f1e9-3148-c5da-7e49-b2fddad9a42f@oss.nttdata.com> Date: Wed, 17 Jun 2020 23:47:28 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------3545A986D5C3245B633DEED2" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------3545A986D5C3245B633DEED2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, The document explains that restart_lsn column in pg_replication_slots view is: The address (LSN) of oldest WAL which still might be required by the consumer of this slot and thus won't be automatically removed during checkpoints. But the latter part is not true in v13 thanks to max_slot_wal_keep_size. I think that we need to update it as follows. Thought? The address (LSN) of oldest WAL which still might be required by the consumer of this slot and thus won't be automatically removed during checkpoints unless this LSN gets behind more than max_slot_wal_keep_size from the current LSN. Patch attached. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION --------------3545A986D5C3245B633DEED2 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="pg_replication_slots_restart_lsn.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pg_replication_slots_restart_lsn.patch" ZGlmZiAtLWdpdCBhL2RvYy9zcmMvc2dtbC9jYXRhbG9ncy5zZ21sIGIvZG9jL3NyYy9zZ21s L2NhdGFsb2dzLnNnbWwKaW5kZXggNzAwMjcxZmQ0MC4uYmYzMjZjZjUzMyAxMDA2NDQKLS0t IGEvZG9jL3NyYy9zZ21sL2NhdGFsb2dzLnNnbWwKKysrIGIvZG9jL3NyYy9zZ21sL2NhdGFs b2dzLnNnbWwKQEAgLTExMjE0LDcgKzExMjE0LDkgQEAgU0VMRUNUICogRlJPTSBwZ19sb2Nr cyBwbCBMRUZUIEpPSU4gcGdfcHJlcGFyZWRfeGFjdHMgcHB4CiAgICAgICA8cGFyYT4KICAg ICAgICBUaGUgYWRkcmVzcyAoPGxpdGVyYWw+TFNOPC9saXRlcmFsPikgb2Ygb2xkZXN0IFdB TCB3aGljaCBzdGlsbAogICAgICAgIG1pZ2h0IGJlIHJlcXVpcmVkIGJ5IHRoZSBjb25zdW1l ciBvZiB0aGlzIHNsb3QgYW5kIHRodXMgd29uJ3QgYmUKLSAgICAgICBhdXRvbWF0aWNhbGx5 IHJlbW92ZWQgZHVyaW5nIGNoZWNrcG9pbnRzLiAgPGxpdGVyYWw+TlVMTDwvbGl0ZXJhbD4K KyAgICAgICBhdXRvbWF0aWNhbGx5IHJlbW92ZWQgZHVyaW5nIGNoZWNrcG9pbnRzIHVubGVz cyB0aGlzIExTTgorICAgICAgIGdldHMgYmVoaW5kIG1vcmUgdGhhbiA8eHJlZiBsaW5rZW5k PSJndWMtbWF4LXNsb3Qtd2FsLWtlZXAtc2l6ZSIvPgorICAgICAgIGZyb20gdGhlIGN1cnJl bnQgTFNOLiAgPGxpdGVyYWw+TlVMTDwvbGl0ZXJhbD4KICAgICAgICBpZiB0aGUgPGxpdGVy YWw+TFNOPC9saXRlcmFsPiBvZiB0aGlzIHNsb3QgaGFzIG5ldmVyIGJlZW4gcmVzZXJ2ZWQu CiAgICAgICA8L3BhcmE+PC9lbnRyeT4KICAgICAgPC9yb3c+Cg== --------------3545A986D5C3245B633DEED2--