From f05ceb978a12b289fe4e3575420b8c9316041e3a Mon Sep 17 00:00:00 2001
From: GitLab Bot <gitlab-bot@gitlab.com>
Date: Wed, 22 Jul 2020 21:09:50 +0000
Subject: Add latest changes from gitlab-org/gitlab@master

---
 config/initializers/database_config.rb       | 43 ++++++++++++++++++++++++----
 config/initializers/postgres_partitioning.rb |  4 ++-
 2 files changed, 41 insertions(+), 6 deletions(-)

(limited to 'config/initializers')

diff --git a/config/initializers/database_config.rb b/config/initializers/database_config.rb
index ce732677c74..79ca6f9354a 100644
--- a/config/initializers/database_config.rb
+++ b/config/initializers/database_config.rb
@@ -20,11 +20,44 @@ Gitlab.ee do
   end
 end
 
-# When running on multi-threaded runtimes like Puma or Sidekiq,
-# set the number of threads per process as the minimum DB connection pool size.
-# This is to avoid connectivity issues as was documented here:
-# https://github.com/rails/rails/pull/23057
-if Gitlab::Runtime.multi_threaded?
+# TODO get rid of feature flag https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/495
+if ENV['DB_USE_NEW_POOL_SIZE_LOGIC'] == '1'
+  # Because of the way Ruby on Rails manages database connections, it is
+  # important that we have at least as many connections as we have
+  # threads. While there is a 'pool' setting in database.yml, it is not
+  # very practical because you need to maintain it in tandem with the
+  # number of application threads. Because of this we override the number
+  # of allowed connections in the database connection pool based on the
+  # configured number of application threads.
+  #
+  # Gitlab::Runtime.max_threads is the number of "user facing" application
+  # threads the process has been configured with. We also have auxiliary
+  # threads that use database connections. Because it is not practical to
+  # keep an accurate count of the number auxiliary threads as the
+  # application evolves over time, we just add a fixed headroom to the
+  # number of user-facing threads. It is OK if this number is too large
+  # because connections are instantiated lazily.
+
+  headroom = (ENV["DB_POOL_HEADROOM"].presence || 10).to_i
+  calculated_pool_size = Gitlab::Runtime.max_threads + headroom
+
+  db_config = Gitlab::Database.config ||
+      Rails.application.config.database_configuration[Rails.env]
+
+  db_config['pool'] = calculated_pool_size
+  ActiveRecord::Base.establish_connection(db_config)
+
+  Gitlab.ee do
+    if Gitlab::Runtime.sidekiq? && Gitlab::Geo.geo_database_configured?
+      Rails.configuration.geo_database['pool'] = calculated_pool_size
+      Geo::TrackingBase.establish_connection(Rails.configuration.geo_database)
+    end
+  end
+elsif Gitlab::Runtime.multi_threaded?
+  # When running on multi-threaded runtimes like Puma or Sidekiq,
+  # set the number of threads per process as the minimum DB connection pool size.
+  # This is to avoid connectivity issues as was documented here:
+  # https://github.com/rails/rails/pull/23057
   max_threads = Gitlab::Runtime.max_threads
   db_config = Gitlab::Database.config ||
       Rails.application.config.database_configuration[Rails.env]
diff --git a/config/initializers/postgres_partitioning.rb b/config/initializers/postgres_partitioning.rb
index 6c8a72d9bd5..b3f12c2ceb1 100644
--- a/config/initializers/postgres_partitioning.rb
+++ b/config/initializers/postgres_partitioning.rb
@@ -3,8 +3,10 @@
 # Make sure we have loaded partitioned models here
 # (even with eager loading disabled).
 
+Gitlab::Database::Partitioning::PartitionCreator.register(AuditEventPartitioned)
+
 begin
-  Gitlab::Database::Partitioning::PartitionCreator.new.create_partitions
+  Gitlab::Database::Partitioning::PartitionCreator.new.create_partitions unless ENV['DISABLE_POSTGRES_PARTITION_CREATION_ON_STARTUP']
 rescue ActiveRecord::ActiveRecordError, PG::Error
   # ignore - happens when Rake tasks yet have to create a database, e.g. for testing
 end
-- 
cgit v1.2.1