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 1joKkM-0007V1-Sp for pgsql-docs@arkaria.postgresql.org; Thu, 25 Jun 2020 05:48:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1joKkL-0008EO-Kv for pgsql-docs@arkaria.postgresql.org; Thu, 25 Jun 2020 05:48:25 +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 1joKkL-0008EH-FO for pgsql-docs@lists.postgresql.org; Thu, 25 Jun 2020 05:48:25 +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 1joKkJ-0007ip-59 for pgsql-docs@lists.postgresql.org; Thu, 25 Jun 2020 05:48:24 +0000 Received: from hnk.local (p2604028-ipngn12401funabasi.chiba.ocn.ne.jp [180.1.110.28]) by oss.nttdata.com (Postfix) with ESMTPSA id 275306029A; Thu, 25 Jun 2020 14:48:19 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com Subject: Re: The description for pg_replication_slots.restart_lsn To: Alvaro Herrera Cc: pgsql-docs@lists.postgresql.org References: <20200625010016.GA22779@alvherre.pgsql> From: Fujii Masao Message-ID: <0414a23a-974c-04d5-ccb0-70ebcc76fcb7@oss.nttdata.com> Date: Thu, 25 Jun 2020 14:48:18 +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 In-Reply-To: <20200625010016.GA22779@alvherre.pgsql> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/06/25 10:00, Alvaro Herrera wrote: > On 2020-Jun-17, Fujii Masao wrote: > >> 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. > > We just added the invalidated_at LSN to replication slots; while working > on the tests for that today, I was thinking that it might be useful to > display that LSN in pg_replication_slots. What do you think of the idea > of publishing the invalidated_at LSN in pg_replication_slot.restart_lsn > when the slot is invalid? I like having separate column for invalidated_at because (at least for me) it's a bit confusing to report the different meaning values in the same column depending on the state. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION