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)),