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 1jTvf3-0003Ra-1f for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Apr 2020 22:58:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jTvf1-0005TJ-IP for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Apr 2020 22:58:35 +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 1jTvf1-0005TC-7u for pgsql-hackers@lists.postgresql.org; Wed, 29 Apr 2020 22:58:35 +0000 Received: from mail-qk1-x742.google.com ([2607:f8b0:4864:20::742]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jTvex-00082v-UY for pgsql-hackers@lists.postgresql.org; Wed, 29 Apr 2020 22:58:34 +0000 Received: by mail-qk1-x742.google.com with SMTP id c63so3900759qke.2 for ; Wed, 29 Apr 2020 15:58:31 -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=dPxgRl8+bYQ0c4l9SK3UTIeNKgF6M6O2R984nlvi4i0=; b=HsqTt20IYG9fqY2JVY3FzVdPTolLfwEZzAX9Qx/95GbZrpIO1d1zUvK++OEe1cWiNA Ni+OLceo3SBS6qmofRl+tF0mPK3zEwmJ1OLwrpniFlP5VebRbyS9F0/oPM8Hp+8yVTYr CrQMBYWcMs1qhZy/TvSW392oUibLc4tHr+USSV8GNHOwHKxLxIiOg4FHaD0MBBLkg4jw zX1CwFjLS+xX8OpLfCHbF8YXJpEn5f1tJVZ92wyVPYnOAu2di7qN5WJvA+KRdaxXv8mL /BqNxPV3WGsgvFXD2SfkYytu7UZcp2wOlNH5MP/dVr7D0MlBo/Qj3q6tkRlSPvGrUv4j XgLg== 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=dPxgRl8+bYQ0c4l9SK3UTIeNKgF6M6O2R984nlvi4i0=; b=Z0T0WvQ3U+eyCHzX2QHDGIKHx9I7UdYTgdFakTck9soT37ogU49Wqd6jv+G8DhbIIk Yq8FrSshc7QsX21sg8fDRV8DidInHbbhtQJ9VTRi/Fuy8zbWEulMGLUmxpAOR2sNR/BJ TmXlsmKl9dxP8ahpRrMdrMzIUNxsxGdUQQBEAAutmjHIQvCHzmmyQxYTQbpNrfklCiH2 4TX5fL71wNzetN8GPSgNXO5tq4YGYZ0hO35d6fpkSFoF6U7CRhDqXmJ7cmpRFLoH390k 7A5sECtqcqk1dSJkZRGV3zu8mWXC35+vZ1YR7aP49nY4ZFu83O2wDFJ4ZehCIXnNnemw X4mg== X-Gm-Message-State: AGi0PuaWFPkIFYd3c9Rsn40U7/qW6W/UjS5iX0a7grZJNGKnJ5BJnDi1 nazTN1AOSiA5+I6om2KDHBOLEw== X-Google-Smtp-Source: APiQypIqe6+pkl129cOWpTV7ak1XObAyDfWIxlWPqRKSyjFXa3P3y2skVVZd66gR8z8qR5WMVzbJpg== X-Received: by 2002:a37:b3c1:: with SMTP id c184mr856781qkf.194.1588201110103; Wed, 29 Apr 2020 15:58:30 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.95.18.252]) by smtp.gmail.com with ESMTPSA id d74sm419597qkc.106.2020.04.29.15.58.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2020 15:58:29 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 40F5E3007D2; Wed, 29 Apr 2020 18:58:16 -0400 (-04) Date: Wed, 29 Apr 2020 18:58:16 -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: <20200429225816.GA18918@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200428231410.GA9805@alvherre.pgsql> 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-28, Alvaro Herrera wrote: > On 2020-Apr-28, Kyotaro Horiguchi wrote: > > > > Anyway I think this patch should fix it also -- instead of adding a new > > > flag, we just rely on the existing flags (since do_checkpoint must have > > > been set correctly from the flags earlier in that block.) > > > > Since the added (!do_checkpoint) check is reached with > > do_checkpoint=false at server start and at archive_timeout intervals, > > the patch makes checkpointer run a busy-loop at that timings, and that > > loop lasts until a checkpoint is actually executed. > > > > What we need to do here is not forgetting the fact that the latch has > > been set even if the latch itself gets reset before reaching to > > WaitLatch. > > After a few more false starts :-) I think one easy thing we can do > without the additional boolean flag is to call SetLatch there in the > main loop if we see that ckpt_flags is nonzero. I went back to "continue" instead of SetLatch, because it seems less wasteful, but I changed the previously "do_checkpoint" condition to rechecking ckpt_flags. We would not get in the busy loop in that case, because the condition is true when the next loop would take action and false otherwise. So I think this should fix the problem without causing any other issues. But if you do see problems with this, please let us know. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services