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 14:33:57 UTC

[couchdb] 01/01: Allow huge Q values

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

vatamane pushed a commit to branch allow-huge-q-values
in repository https://gitbox.apache.org/repos/asf/couchdb.git

commit 271e48d548e471892cf7b7c7a4f0677aeda1d8d6
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..84d82a201 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)),