summaryrefslogtreecommitdiff
path: root/spec/models/postgresql
Commit message (Collapse)AuthorAgeFilesLines
* Remove code related to object hierarchy in MySQLremove-nested-groups-checksHeinrich Lee Yu2019-07-251-1/+1
| | | | | These are not required because MySQL is not supported anymore
* Fix background migrations failing with unused replication slotsh-handle-nil-replication-lagStan Hu2019-06-251-0/+8
| | | | | | | | When there is an unused replication slot, the replication lag function will return a nil value, resulting in "NoMethodError: undefined method `>=' for nil:NilClass" error. We now just ignore these nil values. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63666
* Disable replication lag check for Aurora PostgreSQL databasessh-fix-issue-52176Stan Hu2018-11-031-0/+20
| | | | | | | | | | | | | | | | | | | | Replication slots are not supported in Aurora. Attempting to check the lag results in the message: ``` ActiveRecord::StatementInvalid: PG::FeatureNotSupported: ERROR: Replication slots are currently not supported in Aurora : SELECT pg_xlog_location_diff(pg_current_xlog_insert_location(), restart_lsn)::... ``` To avoid breaking support for background migrations in Aurora, we just disable the check if we encounter this error. This change also now checks whether there are any replication slots present in the primary before checking the replication lag. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/52176
* Respond to DB health in background migrationsYorick Peterse2018-08-061-0/+31
This changes the BackgroundMigration worker so it checks for the health of the DB before performing a background migration. This in turn allows us to reduce the minimum interval, without having to worry about blowing things up if we schedule too many migrations. In this setup, the BackgroundMigration worker will reschedule jobs as long as the database is considered to be in an unhealthy state. Once the database has recovered, the migration can be performed. To determine if the database is in a healthy state, we look at the replication lag of any replication slots defined on the primary. If the lag is deemed to great (100 MB by default) for too many slots, the migration is rescheduled for a later point in time. The health checking code is hidden behind a feature flag, allowing us to disable it if necessary.