You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@couchdb.apache.org by va...@apache.org on 2022/10/06 15:16:39 UTC

[couchdb] branch main updated: Allow huge Q values

This is an automated email from the ASF dual-hosted git repository.

vatamane pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/couchdb.git


The following commit(s) were added to refs/heads/main by this push:
     new 228b07ead Allow huge Q values
228b07ead is described below

commit 228b07ead3c9795bf41cddaa43ae4e43029e28a6
Author: Nick Vatamaniuc <va...@gmail.com>
AuthorDate: Thu Oct 6 10:31:37 2022 -0400

    Allow huge Q values
    
    These may not be practical but our arithmetic blowing up shouldn't be the limit
    preventing it.
    
    Use the minimum timeout when the number of shards is greater than 64.
    
    Fixes: https://github.com/apache/couchdb/issues/4196
---
 src/fabric/src/fabric_util.erl | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/src/fabric/src/fabric_util.erl b/src/fabric/src/fabric_util.erl
index 34e095403..fbba5bdf8 100644
--- a/src/fabric/src/fabric_util.erl
+++ b/src/fabric/src/fabric_util.erl
@@ -159,6 +159,9 @@ get_db_timeout(N, Factor, MinTimeout, infinity) ->
     % MaxTimeout may be infinity so we just use the largest Erlang small int to
     % avoid blowing up the arithmetic
     get_db_timeout(N, Factor, MinTimeout, 1 bsl 59);
+get_db_timeout(N, _Factor, MinTimeout, _MaxTimeout) when N > 64 ->
+    % Guard against max:pow/2 blowing from a large exponent
+    MinTimeout;
 get_db_timeout(N, Factor, MinTimeout, MaxTimeout) ->
     %
     % The progression of timeouts forms a geometric series:
@@ -446,6 +449,9 @@ get_db_timeout_test() ->
     % Q=256, N=3
     ?assertEqual(100, get_db_timeout(256 * 3, 2, 100, 60000)),
 
+    % Q=9999 N=3
+    ?assertEqual(100, get_db_timeout(9999 * 3, 2, 100, 60000)),
+
     % Large factor = 100
     ?assertEqual(100, get_db_timeout(2 * 3, 100, 100, 60000)),