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 1jLwyR-0000kJ-Hx for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2020 22:45:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jLwyQ-0001TK-D2 for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2020 22:45:38 +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 ) id 1jLwyQ-0001Qv-1U for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2020 22:45:38 +0000 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jLwyN-0001xp-97 for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2020 22:45:37 +0000 Received: by mail-qt1-x842.google.com with SMTP id s10so2545438qtn.10 for ; Tue, 07 Apr 2020 15:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=d3yyE9CnCc3ex9ph3WYLqDf/Jtd5mDgSPDbOg2sFWNE=; b=hzAqVMjLdnKxLzgUlUy9GyqlaSYVA9vz+nRd1vidK58Muh/AcO0LDW32XwidD8LRxk Zipj557LKPw+y5XRqhr/QHSP8g46q5jhShSd8uopNr1tQ9/ouhSb4Hs27I7z/yOBf1pI NSko/tzKls9jLCPzP3X4+ARUSqo34R3AYLrPqH2R5r8IKBYSA5Bp22TGmbx5hic1EE8a W3lCI6OkgdAp8O8esEmnlrygB/n2YxLPV0LBiV6aJ7fgEWyBLmMCmC7ELnZWVqVpM/5f LAVdkEdgiHu1i1xF2P4n2BXQ6wMA9tjd1Qb8cZFZWdnl5iUN1zYj9BZi8sdOjhghdcsS Nj8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=d3yyE9CnCc3ex9ph3WYLqDf/Jtd5mDgSPDbOg2sFWNE=; b=K6YcfCG6bQmig3wyhilzN9GoTqYCiBmDyO/DynmyyujqSwOmkg4NoGEBR1lAEuvkdp L+PwLn7y8BKon1ok5IyD8eOu/NzFVapAEuCJsDnpDI6Qo+FVijOGT9jm//FJFBgxCdza IW60BmdSnd+FQWQJ+mnlgcFI3gvXjsI9ID8VNlzDfPifh/fMdSUcvMdg/qqu7JQS110m Se1Raoc6pllratRtxgd5PtgeFr9VVuozdKRa+VY85jn+LsQkXBh6mV9xAkqCmEvr95vM udrQfIhLk3FQLwWlVnEXKzdt/1Akikg7OLYy3BXm9ufWc9t1aaZZFTIwiTz0kZMeIWuG bivQ== X-Gm-Message-State: AGi0PubHwDiPXnBkmxoZy4Bc97djhCJxaoDZymheojh0p1DDbtPG6726 3qXrM8P/ounk+c5qF0+tzGXVlg== X-Google-Smtp-Source: APiQypJ6fYKxxWo4I8Wjrq4K/72qRsiXnaw3AnCn00o0OS2EZ4X+SoE9rJk7wkDATiZNbwX/maS2uw== X-Received: by 2002:ac8:4e13:: with SMTP id c19mr4583491qtw.80.1586299533586; Tue, 07 Apr 2020 15:45:33 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.95.18.252]) by smtp.gmail.com with ESMTPSA id q142sm17586177qke.45.2020.04.07.15.45.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2020 15:45:32 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id E76DE300A5A; Tue, 7 Apr 2020 18:45:22 -0400 (-04) Date: Tue, 7 Apr 2020 18:45:22 -0400 From: Alvaro Herrera To: Kyotaro Horiguchi Cc: jgdr@dalibo.com, andres@anarazel.de, michael@paquier.xyz, sawada.mshk@gmail.com, peter.eisentraut@2ndquadrant.com, pgsql-hackers@lists.postgresql.org, thomas.munro@enterprisedb.com, sk@zsrv.org, michael.paquier@gmail.com Subject: Re: [HACKERS] Restricting maximum keep segments by repslots Message-ID: <20200407224522.GA18671@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200407.163043.2050717072576572791.horikyota.ntt@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Apr-07, Kyotaro Horiguchi wrote: > > Mmm. Couldn't we have a new member 'invalidated' in ReplicationSlot? > > I did that in the attached. The invalidated is shared-but-not-saved > member of a slot and initialized to false then irreversibly changed to > true when the slot loses required segment. > > It is checked by the new function CheckReplicationSlotInvalidated() at > acquireing a slot and at updating slot by standby reply message. This > change stops walsender without explicitly killing but I didn't remove > that code. This change didn't work well with my proposed change to make checkpointer acquire slots before marking them invalid. When I incorporated your patch in the last version I posted yesterday, there was a problem that when checkpointer attempted to acquire the slot, it would fail with "the slot is invalidated"; also if you try to drop the slot, it would obviously fail. I think it would work to remove the SlotIsInvalidated check from the Acquire routine, and instead move it to the routines that need it (ie. not the InvalidateObsolete one, and also not the routine to drop slots). I pushed version 26, with a few further adjustments. I think what we have now is sufficient, but if you want to attempt this "invalidated" flag on top of what I pushed, be my guest. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services