Add Michał Zając to database maintainers

Background

• GitLab employee since January 2020 (2+ year)
• Database trainee maintainer for 1+ year

Database Trainee Maintainer

• Did around 80 database reviews (didn't add everything to the trainee issue since most of them were add/remove column but I can go back if needed)
• Most of them merged as is
• Changes to documentation:
  • Add details about track_jobs to Background migrations docs
  • Add information about The Art Of PostgreSQL training
  • Link to Constraint naming convention in guidelines (gitlab-org/gitlab!92099 - merged)
• Other changes:
  • Do not require backend review for migration specs

Interesting/tricky reviews

• gitlab-org/gitlab!58123 (merged) - I did manage to squeeze out some performance but there was a simpler solution to the problem
• gitlab-org/gitlab!56722 (merged) - much to my surprise add_column silently swallows invalid options – gitlab-org/gitlab!56722 (comment 596160373)
• gitlab-org/gitlab!54608 (merged) - this went through without many problems but we didn't estimate the performance implications correctly leading to gitlab-org/gitlab#329436 (closed)
• gitlab-org/gitlab!61645 (closed) - we couldn't speed up the queries anymore so this never got merged but an alternative solution is being implemented in gitlab-org/gitlab!63676 (closed) and gitlab-org/gitlab!63700 (closed)
• gitlab-org/gitlab!59842 (comment 559040587) - I was surprised to learn that Rails doesn't try to match the referencesdoesn't take the source type into consideration and just slaps abigint` there

Becoming DB Maintainer

I'm not new to database development and administration and I kind of "knew" that things work differently at this scale but only when I actually started working on DB changes, I understood what kind of problems we're facing and that even "simple" changes, like adding foreign keys, can cause problems. At this point I can comfortably say that I'd be a good asset on the maintainer team but I'll still have much to learn (especially after gitlab-org/gitlab!60023 (comment 563191472), I swear I wouldn't be able to come up with this myself)

Closes #8084 (closed)

Pinging @gitlab-org/maintainers/database for discussion

/cc @thiagocsf

Developer checklist

• Before this MR is merged
  • Mention @gitlab-org/maintainers/database, if not done (this issue template should do this automatically)
  • Assign this issue to your manager
• After this MR is merged
  • Consider adding 'database maintainer' to your Slack notification keywords
  • Add yourself to the #database_maintainers slack channel

Manager checklist

• Before this MR is merged
  • The MR has been open for 5 working days
  • More than half of the existing maintainers approve the MR (see the maintainer list)
  • There are no blocking concerns raised (if there are, please follow https://about.gitlab.com/handbook/engineering/workflow/code-review/#how-to-become-a-project-maintainer)
• After this MR is merged
  • Announce the good news in the relevant channels listed in https://about.gitlab.com/handbook/engineering/#keeping-yourself-informed

Updates after 2021-10-13

Reviews

I'm not going to include merged as-is reviews here since I still track all reviews in Database Trainee Maintainer: Michał Zając (#8084 - closed)

MR	Suggestions	After maintainer review
Add VulnerabilityStateTransition model (gitlab-org/gitlab!87957 - merged)	Adding a composite index, no proper description	Index creation was moved to a follow-up issue
Add a index for vulnerability_state_transitions... (gitlab-org/gitlab!88875 - merged)	None	I missed the fact that remove-and-create will leave us with a small window of no-index-at-all
Cleanup orphaned routes (gitlab-org/gitlab!88401 - merged)	Suggested reducing the batch size to 100k	Merged as-is
Add a service to promote security findings to v... (gitlab-org/gitlab!88472 - merged)	Suggested creating an index to get the query performance we need	Merged as-is

Database merge requests authored

Since the issue description doesn't say I should include those, I never did so here's a tl;dr of what database changes I authored since joining. I'm going to skip merged as-is MRs here as well

UUIDv4 to UUIDv5 migration

Long story short: vulnerability_occurrences table used UUIDv4 (time-based) which gave us no stability when it came to determining whether the vulnerability found was the same or not. At some point we realized UUIDv5 was a thing and decided to use it.

1. We start calculating UUIDv5, falling back to UUIDv4 if something goes wrong – gitlab-org/gitlab!43881 (merged)
2. Work started on gitlab-org/gitlab!47529 (merged)
3. I realize we will get duplicates for some records so we attempt to remove them – gitlab-org/gitlab!49937 (merged) (this went pretty well considering we even had triplicates)
4. At this point we're ready to recalculate UUIDs to version 5 – I thought this would be simpler if we enabled uuid-ossp extension but wasn't doable back then I think
5. This worked, unfortunately we missed the fact that two columns used to calculate UUIDv5 are bytea so we needed to use ShaAttribute mixin in the migration code – https://gitlab.com/gitlab-org/gitlab/-/issues/341917
6. Before retrying we also drop records from vulnerabilities that would have no corresponding vulnerability_occurrences entry – gitlab-org/gitlab!71752 (merged)
7. That fails due to timeout on cascading drops – https://gitlab.com/gitlab-org/gitlab/-/issues/341917#note_722669833
8. We drop them via a background migration – gitlab-org/gitlab!74008 (merged)
9. At this point we need to recalculate UUIDs again. At the same we introduce tracking signatures so the vulnerability tracking is more stable.
10. We attempt scheduling again in – gitlab-org/gitlab#341195 (closed)
11. I realize that we have a tricky situation and can't just stop ingesting security reports
12. Finally we're able to create a combination background migration that does everything in one go – gitlab-org/gitlab!75546 (merged)

Not exactly the easiest migration. There are still some tasks to do with regards to our uuid column like column type migration. There are other database initiatives in Threat Insights that I'm part of like Deprecate and remove Vulnerabilities::Feedback (gitlab-org&5629 - closed)

Other MRs

MR	Reviewer suggestions	Maintainer suggestions	Notes
Create index on security_findings asynchronously (gitlab-org/gitlab!91884 - merged)	Rename index to be closer with conventions	None	None
Add index on security_findings(uuid id DESC) (gitlab-org/gitlab!91885 - merged)	None	None	Not merged yet because we are waiting until index gets created
Link to Constraint naming convention in guidelines (gitlab-org/gitlab!92099 - merged)	None	None	Documentation change
Create `Vulnerabilities::MergeRequestLink` model (gitlab-org/gitlab!92096 - merged)	Redundant indexes added	TBA