Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iAJhd-0005gD-5J for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Sep 2019 20:03:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iAJhb-0000hk-JV for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Sep 2019 20:03:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iAJhb-0000hO-AR for pgsql-hackers@lists.postgresql.org; Tue, 17 Sep 2019 20:03:55 +0000 Received: from mail-qk1-x72e.google.com ([2607:f8b0:4864:20::72e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iAJhT-0008RX-Ty for pgsql-hackers@lists.postgresql.org; Tue, 17 Sep 2019 20:03:54 +0000 Received: by mail-qk1-x72e.google.com with SMTP id u186so5415217qkc.5 for ; Tue, 17 Sep 2019 13:03:47 -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=Fyj0qb0TbhQdqn3zMCsokC/+0KoInIrV2lOdc1Y2s1Q=; b=Y4ErLni7An3RdhM0nbUiMTRZsYxHBnuHypqW4tCcsQnTaNRAZJJTgfU5DngqBjNMTE xGVSGy0Hg9HgTTxZxgqWmuAmcTxrfxRYQYShmiM/vomxW77kGPyYcw11jYbhxIbE2xZW ydOSG5PvVf3A8W3P9Dk7ept2ngjrxTdpKtKqeUCRKaoaXRIAzTyPO3UVLdINBbAIJrCV DHf4jwLhkgI+VNJg1UnJGqLBwT1nUWAACPKfKmvjRlUFmzaNDbQRifKgbZ0pm1Xorjzq sizWHT4RBq9XDQiW/EIolb7/P+0fjbM3DJN9EKHhqkIJUvd2w1JerfngZ8fEsAhObyQv LCZQ== 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=Fyj0qb0TbhQdqn3zMCsokC/+0KoInIrV2lOdc1Y2s1Q=; b=qmse0qAATxc0Uioq4+FuJxB9diFyieywjEzVc/EeH5JkgVcVa7jk7EbxA3aBFwJAd3 mexZx/2/Rw1oJTMELJH+2NzDc27dttQdGUSAoH3pvIiRAwVtl88I1O6HeLLXgbE8uO1k aPrEI3g02eIU3pmD4xFKPqisnrmK11ScUKzQ4k/eO9o03TKbx80L4CSSmYFZpWVH3Vxq E9PF0Jl6B+m7rBtrlcQ34X/wXMIzjcleRsyBZzgcOca/6DnJteq91lhDQss+M4QoFtLo 0SbCRGDnC3ctl9oKxZ/+UsDktAFCb+RxAb73Cw3UrkMC6Hty6v6jeToNoYGq1YSDvMQv 66hw== X-Gm-Message-State: APjAAAXcdVh1BlPHsW1Ma+KYbzRG8LxmIMYkm3MPLJw/1rAeNOhBXWEg lSBJziZMUBfZ2PkLJTA32cz6Pw== X-Google-Smtp-Source: APXvYqyKhCAE4s1EEYYqq9vXfwU9S9xQHcBMeurmEDRMZsKbcXyk5XAGDPOQEqmEtJKE0HT7AwLuPQ== X-Received: by 2002:a37:a683:: with SMTP id p125mr216607qke.173.1568750625783; Tue, 17 Sep 2019 13:03:45 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([191.126.99.92]) by smtp.gmail.com with ESMTPSA id w73sm1756202qkb.111.2019.09.17.13.03.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Sep 2019 13:03:45 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 4278D120F1C; Tue, 17 Sep 2019 16:58:00 -0300 (-03) Date: Tue, 17 Sep 2019 16:58:00 -0300 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: <20190917195800.GA16694@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190731.165616.261402513.horikyota.ntt@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello I have a couple of API-level reservation about this patch series. Firstly, "behind" when used as a noun refers to buttocks. Therefore, the ReplicationSlotsEnumerateBehinds function name seems funny (I think when used as a preposition you wouldn't put it in plural). I don't suggest a substitute name, because the API itself doesn't convince me; I think it would be sufficient to have it return a single slot name, perhaps the one that is behind the most ... or maybe the one that is behind the least? This simplifies a lot of code (in particular you do away with the bunch of statics, right?), and I don't think the warning messages loses anything, because for details the user should really look into the monitoring view anyway. I didn't like GetLsnAvailability() returning a string either. It seems more reasonable to me to define a enum with possible return states, and have the enum value be expanded to some string in pg_get_replication_slots(). In the same function, I think that setting restBytes to -1 when "useless" is bad style. I would just leave that variable alone when the returned status is not one that receives the number of bytes. So the caller is only entitled to read the value if the returned enum value is such-and-such ("keeping" and "streaming" I think). I'm somewhat uncomfortable with the API change to GetOldestKeepSegment in 0002. Can't its caller do the math itself instead? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services