Skip to content

Create partitioned table for uploads

What does this MR do and why?

Adds uploads_9ba8c4165 partitoned by model_type and a trigger to sync it on writes to uploads. This is in preparation of replacing the existing uploads table with the partitioned one.

See #398199.

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Risks

Since the uploads table has no FKs to organizations, namespaces, and projects, but uploads_9ba88c4165 does, there is some risk that there is an error when the sync trigger inserts or updates records in uploads_9ba88c4165. This was discussed in !175203 (comment 2310958275). In summary - it should be fine to keep the sync trigger as is:

  • UPDATE on uploads
    • Record does not exist in uploads_9ba88c4165 - this will be a no-op.
    • Record does exist in uploads_9ba88c4165 - if it's already there, it will be linked to existing organization/namespace/project because of the FK we have on the table. Updating it so that it points to a non-existing organization/namespace/project does not make sense, and it's OK to let this fail. We pretty much never update records in uploads anyway (see https://dashboards.gitlab.net/goto/ZeqN7KdNg?orgId=1).
  • INSERT on uploads
    • Trying to create an upload that is linked to non-existing organization/namespace/project does not make sense either, it's OK to let this fail too.

Rollback

In case this cause any issues when deployed on production, we can mitigate them by removing the trigger:

  • Open psql console on the main database primary node.
  • Execute
      DROP TRIGGER table_sync_trigger_4ea4473e79 ON uploads;

Monitoring

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Related to #398199

Edited by Krasimir Angelov

Merge request reports

Loading