- 20 Nov, 2017 1 commit
-
-
Bob Van Landuyt authored
When a project is using hashed storage, the repositories and attachments wouldn't be saved on disk using the `full_path`. So the migration would not do anything. However: best to just skip moving when hashed storage is enabled.
-
- 17 Nov, 2017 1 commit
-
-
Sean McGivern authored
-
- 06 Nov, 2017 1 commit
-
-
Yorick Peterse authored
This ensures we can check if the user has TRIGGER permissions without querying restricted tables. Thanks to Steve Norman (https://gitlab.com/stevenorman) for helping out with this merge request. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/38372
-
- 15 Sep, 2017 1 commit
-
-
Yorick Peterse authored
Prior to this commit running Namespace#force_share_with_group_lock_on_descendants would result in updating _all_ namespaces in the namespaces table, not just the descendants. This is the result of ActiveRecord::Relation#update_all not taking into account the CTE. To work around this we use the CTE query as a sub-query instead of directly calling #update_all. To prevent this from happening the relations returned by Gitlab::GroupHierarchy are now marked as read-only, resulting in an error being raised when methods such as #update_all are used. Fortunately on GitLab.com our statement timeouts appear to have prevented this query from actually doing any damage other than causing a very large amount of dead tuples. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37916
-
- 14 Sep, 2017 2 commits
-
-
Michael Kozono authored
-
Michael Kozono authored
-
- 29 Aug, 2017 1 commit
-
-
Yorick Peterse authored
This adds a bunch of checks to migrations that may create or drop triggers. Dropping triggers/functions is done using "IF EXISTS" so we don't throw an error if the object in question has already been dropped. We now also raise a custom error (message) when the user does not have TRIGGER privileges. This should prevent the schema from entering an inconsistent state while also providing the user with enough information on how to solve the problem. The recommendation of using SUPERUSER permissions is a bit extreme but we require this anyway (Omnibus also configures users with this permission). Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36633
-
- 23 Aug, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 22 Aug, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 20 Aug, 2017 1 commit
-
-
Stan Hu authored
Due to a missing `on_delete: :cascade`, users would hit the error that looked like: ``` PG::ForeignKeyViolation: ERROR: update or delete on table "protected_tags" violates foreign key constraint "fk_rails_f7dfda8c51" on table "protected_tag_create_access_levels" DETAIL: Key (id)=(1385) is still referenced from table "protected_tag_create_access_levels". : DELETE FROM "protected_tags" WHERE "protected_tags"."id" = 1385 ``` Closes #36013
-
- 18 Jul, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 11 Jul, 2017 1 commit
-
-
Paul Charlton authored
-
- 07 Jul, 2017 7 commits
-
-
James Lopez authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
James Lopez authored
-
- 29 Jun, 2017 1 commit
-
-
Yorick Peterse authored
These attributes are stored in binary in the database, but exposed as strings. This allows one to query/create data using plain SHA1 hashes as Strings, while storing them more efficiently as binary.
-
- 27 Jun, 2017 2 commits
-
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
- 26 Jun, 2017 11 commits
-
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
- 21 Jun, 2017 2 commits
-
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
- 19 Jun, 2017 1 commit
-
-
Yorick Peterse authored
When using update_column_in_batches the upper limit on the batch size is now 1000. This ensures that for very large tables we don't lock tens of thousands of rows during the update. This in turn should reduce the likelyhood of running into deadlocks.
-
- 13 Jun, 2017 1 commit
-
-
blackst0ne authored
-
- 25 May, 2017 1 commit
-
-
Nick Thomas authored
-
- 18 May, 2017 1 commit
-
-
Bob Van Landuyt authored
-
- 15 May, 2017 1 commit
-
-
Douwe Maan authored
-