Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rQq3k-003q4s-TM for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jan 2024 14:41:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rQq3k-009w7l-2U for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jan 2024 14:41:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rQq3j-009w7d-OV for pgsql-hackers@lists.postgresql.org; Fri, 19 Jan 2024 14:41:27 +0000 Received: from pitta.toroid.org ([136.243.148.74]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rQq3c-002KYZ-St for pgsql-hackers@lists.postgresql.org; Fri, 19 Jan 2024 14:41:26 +0000 Received: from kathal.lweshal.in (unknown [10.2.1.2]) by pitta.toroid.org (Postfix) with ESMTP id C6190FA37B5; Fri, 19 Jan 2024 15:41:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=toroid.org; s=mail; t=1705675277; bh=ZcS8DCtV6wtp9p32tnbi4/TFrbGHBrxZuvTMXHlkm9k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bElwTGxYCmoOiZy55dzmUG1NKva6tfvp78vfb/lwelkHdRF8zJQUOqY8e7n8fb5JL ximJVkpefBApHoPTFLDl7YEV8biFJBXUzF3Q9L8J2VNRqJIeRYfG8gFjjIBj9CCPhR rpms4PAO/vUM4eNj85SoypFI7k/Y8VEuQLiEoRup60tbSxBQ44Zk7fYq1uXy9UugAL a6helyc4Sn+NRrSquIAqh3Pv8y8GRZDv/C8fMVLhKeFKpsVkftBEulEOUJuv5C5ojJ q1l4LYKOGqcynl+hWYL0SEJjDCyNWQLJFoaCz0ZJEi0bK0iWSVloEKz2Sa2VNKCVuj bG3+Dv4/PFT2w== Received: from ams by kathal.lweshal.in with local (Exim 4.96) (envelope-from ) id 1rQq3Y-002b1Y-0M; Fri, 19 Jan 2024 20:11:16 +0530 Date: Fri, 19 Jan 2024 20:11:16 +0530 From: Abhijit Menon-Sen To: Michael Banck Cc: pgsql-hackers@lists.postgresql.org, =?utf-8?B?5oiQ5LmL54SV?= Subject: Re: [PATCH] Exponential backoff for auth_delay Message-ID: References: <658c4eab.050a0220.731ff.011e@mx.google.com> <65965e9d.050a0220.919a6.f9e1@mx.google.com> <65aa8265.170a0220.1ecef.91df@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65aa8265.170a0220.1ecef.91df@mx.google.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At 2024-01-19 15:08:36 +0100, mbanck@gmx.net wrote: > > I wonder whether maybe auth_delay.max_seconds should either be renamed > to auth_delay.exponential_backoff_max_seconds (but then it is rather > long) in order to make it clearer it only applies in that context or > alternatively just apply to auth_delay.milliseconds as well (though > that would be somewhat weird). I think it's OK as-is. The description/docs are pretty clear. > I wonder though whether this might be a useful message to have at some > more standard level like INFO? I don't have a strong opinion about this, but I suspect anyone who is annoyed enough by repeated authentication failures to use auth_delay will also be happy to have less noise in the logs about it. > You mean something like "after 5 minutes, reset the delay to 0 again"? > I agree that this would probably be useful, but would also make the > change more complex. Yes, that's the kind of thing I meant. I agree that it would make this patch more complex, and I don't think it's necessary to implement. However, since it's a feature that seems to go hand-in-hand with exponential backoff in general, it _may_ be good to mention in the docs that the sleep time for a host is reset only by successful authentication, not by any timeout. Not sure. > What I had in mind is that admins would lower auth_delay.milliseconds to > something like 100 or 125 when exponential_backoff is on Ah, that makes a lot of sense. Thanks for explaining. Your new v3 patch looks fine to me. I'm marking it as ready for committer. -- Abhijit