dev:setup can't be used easily in EE due to database sessions
In EE, there is a high likelihood a Sidekiq job will run and hang onto the connection. When rake dev:setup runs, it will fail with:
Caused by:
PG::ObjectInUse: ERROR: database "gitlabhq_development" is being accessed by other users
DETAIL: There are 3 other sessions using the database.
/tmp/gdk-ee-test/gitlab/lib/tasks/gitlab/setup.rake:28:in `setup_db'
/tmp/gdk-ee-test/gitlab/lib/tasks/gitlab/setup.rake:5:in `block (2 levels) in <main>'
/tmp/gdk-ee-test/gitlab/lib/tasks/dev.rake:7:in `block (2 levels) in <main>'
/home/stanhu/.rbenv/versions/2.5.3/bin/bundle:23:in `load'
/home/stanhu/.rbenv/versions/2.5.3/bin/bundle:23:in `<main>'
Tasks: TOP => db:drop:_unsafe
(See full trace by running task with --trace)For example, my Geo instance has these jobs running:
datid | datname | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | xact_start | query_start | state_change | waiting | state | backend_xid | backend_xmin | query
-------+----------------------+-------+----------+---------+-------------------------------------+-------------+-----------------+-------------+-------------------------------+-------------------------------+-------------------------------+-------------------------------+---------+--------+-------------+--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
16386 | gitlabhq_development | 2470 | 10 | stanhu | sidekiq 5.2.5 gitlab [0 of 10 busy] | | | -1 | 2019-01-28 21:47:42.672154+00 | | 2019-01-28 22:17:15.859927+00 | 2019-01-28 22:17:15.859954+00 | f | idle | | | SELECT 1 AS one FROM "geo_nodes" LIMIT $1
16386 | gitlabhq_development | 17274 | 10 | stanhu | sidekiq 5.2.5 gitlab [0 of 10 busy] | | | -1 | 2019-01-28 22:00:25.253665+00 | | 2019-01-28 22:17:15.85135+00 | 2019-01-28 22:17:15.851418+00 | f | idle | | | SELECT "projects".* FROM "projects" INNER JOIN project_mirror_data import_state ON import_state.project_id = projects.id WHERE "projects"."mirror" = $1 AND ("import_state"."status" NOT IN ('scheduled', 'started')) AND (import_state.next_execution_timestamp <= '2019-01-28 22:17:15.848159') AND (import_state.retry_count <= 14) ORDER BY import_state.next_execution_timestamp LIMIT $2
16386 | gitlabhq_development | 2854 | 10 | stanhu | sidekiq 5.2.5 gitlab [0 of 10 busy] | | | -1 | 2019-01-28 21:48:03.734564+00 | | 2019-01-28 22:17:15.861852+00 | 2019-01-28 22:17:15.861918+00 | f | idle | | | SELECT "ci_builds".* FROM "ci_builds" WHERE "ci_builds"."type" IN ('Ci::Build') AND "ci_builds"."status" IN ('success', 'failed', 'canceled') AND (EXISTS (SELECT 1 FROM "ci_build_trace_chunks" WHERE (ci_builds.id = ci_build_trace_chunks.build_id))) ORDER BY "ci_builds"."id" ASC LIMIT $1
16386 | gitlabhq_development | 17275 | 10 | stanhu | sidekiq 5.2.5 gitlab [0 of 10 busy] | | | -1 | 2019-01-28 22:00:25.26189+00 | | 2019-01-28 22:16:15.138618+00 | 2019-01-28 22:16:15.138684+00 | f | idle | | | SELECT "projects".* FROM "projects" INNER JOIN project_mirror_data import_state ON import_state.project_id = projects.id WHERE "projects"."mirror" = $1 AND ("import_state"."status" NOT IN ('scheduled', 'started')) AND (import_state.next_execution_timestamp <= '2019-01-28 22:16:15.135088') AND (import_state.retry_count <= 14) ORDER BY import_state.next_execution_timestamp LIMIT $2
16386 | gitlabhq_development | 17276 | 10 | stanhu | sidekiq 5.2.5 gitlab [0 of 10 busy] | | | -1 | 2019-01-28 22:00:25.273238+00 | | 2019-01-28 22:18:15.663713+00 | 2019-01-28 22:18:15.663735+00 | f | idle | | | SELECT 1 AS one FROM "geo_nodes" LIMIT $1
16386 | gitlabhq_development | 17277 | 10 | stanhu | sidekiq 5.2.5 gitlab [0 of 10 busy] | | | -1 | 2019-01-28 22:00:25.290904+00 | | 2019-01-28 22:18:15.65868+00 | 2019-01-28 22:18:15.658735+00 | f | idle | | | SELECT "projects".* FROM "projects" INNER JOIN project_mirror_data import_state ON import_state.project_id = projects.id WHERE "projects"."mirror" = $1 AND ("import_state"."status" NOT IN ('scheduled', 'started')) AND (import_state.next_execution_timestamp <= '2019-01-28 22:18:15.654793') AND (import_state.retry_count <= 14) ORDER BY import_state.next_execution_timestamp LIMIT $2
16386 | gitlabhq_development | 5043 | 10 | stanhu | psql | | | -1 | 2019-01-28 22:17:38.786595+00 | 2019-01-28 22:18:32.191893+00 | 2019-01-28 22:18:32.191893+00 | 2019-01-28 22:18:32.191897+00 | f | active | | 3212 | select * from pg_stat_activity;
(7 rows)We might be able to fix this by cancelling all connections to the DB before dropping it: https://stackoverflow.com/a/13245265
/cc: @sbigelow