BigW Consortium Gitlab

  1. 24 May, 2017 2 commits
  2. 22 May, 2017 1 commit
  3. 18 May, 2017 1 commit
  4. 15 May, 2017 1 commit
  5. 12 May, 2017 2 commits
  6. 01 May, 2017 11 commits
  7. 12 Apr, 2017 1 commit
    • Prepare for zero downtime migrations · 223d8a3d
      Yorick Peterse authored
      Starting with GitLab 9.1.0 we will no longer allow downtime migrations
      unless absolutely necessary. This commit updates the various developer
      guides and adds code that is necessary to make zero downtime migrations
      less painful.
  8. 11 Apr, 2017 1 commit
  9. 05 Apr, 2017 1 commit
  10. 23 Feb, 2017 2 commits
  11. 21 Feb, 2017 1 commit
    • Hash concurrent foreign key names similar to Rails · 79696f5b
      Yorick Peterse authored
      This was initially not implemented simply because I forgot about the
      size limit of constraint names in PostgreSQL (63 bytes). Using the old
      technique we can't add foreign keys for certain tables. For example,
      adding a foreign key on
      protected_branch_merge_access_levels.protected_branch_id would lead to
      the following key name:
      
          fk_protected_branch_merge_access_levels_protected_branches_protected_branch_id
      
      This key is 78 bytes long, thus violating the PostgreSQL size
      requirements.
      
      The hashing strategy is copied from Rails' foreign_key_name() method,
      which unfortunately is private and subject to change without notice.
  12. 10 Feb, 2017 1 commit
    • Add method for creating foreign keys concurrently · a97dcc07
      Yorick Peterse authored
      This method allows one to create foreign keys without blocking access to
      the source table, but only on PostgreSQL.
      
      When creating a regular foreign key the "ALTER TABLE" statement used for
      this won't return until all data has been validated. This statement in
      turn will acquire a lock on the source table. As a result this lock can
      be held for quite a long amount of time, depending on the number of rows
      and system load.
      
      By breaking up the foreign key creation process in two steps (creation,
      and validation) we can reduce the amount of locking to a minimum.
      Locking is still necessary for the "ALTER TABLE" statement that adds the
      constraint, but this is a fast process and so will only block access for
      a few milliseconds.
  13. 16 Sep, 2016 2 commits
  14. 15 Jul, 2016 1 commit
  15. 16 Jun, 2016 2 commits
  16. 15 Jun, 2016 2 commits
    • Don't update columns in batches in a transaction · 816c4535
      Yorick Peterse authored
      This ensures that whatever locks are acquired aren't held onto until the
      end of the transaction (= after _all_ rows have been updated). Timing
      wise there's also no difference between using a transaction and not
      using one.
    • Customizing of update_column_in_batches queries · 8966263e
      Yorick Peterse authored
      By passing a block to update_column_in_batches() one can now customize
      the queries executed. This in turn can be used to only update a specific
      set of rows instead of simply all the rows in the table.
  17. 13 Jun, 2016 1 commit
  18. 06 Jun, 2016 1 commit
  19. 03 Jun, 2016 2 commits
  20. 22 May, 2016 2 commits
  21. 12 May, 2016 2 commits