Developer Documents First GitLab Contribution: A Fillfactor Migration for Two Vulnerability Tables

A developer writing on dev.to has published a first-person account of making a first contribution to the GitLab codebase, describing the path from selecting an issue through opening a merge request. The post is a community write-up rather than an official GitLab announcement, so every detail below is the author's own account and has not been independently verified.

According to the author, the work began with a search through GitLab issues flagged as suitable for community contribution. The issue chosen was #629994, titled "Lower fillfactor on the vulnerability identifier tables," which concerned two tables: vulnerability_identifiers and vulnerability_occurrence_identifiers.

The author states that the issue included measurements showing relatively low HOT-update fractions for those tables, and that this was the motivation for the change. The reported figures were approximately 32.0 percent for vulnerability_identifiers and 64.2 percent for vulnerability_occurrence_identifiers. The author presents these numbers as coming from the issue, not from independent measurement.

How the request works at the PostgreSQL level is explained in the post. Rows of a table are kept by PostgreSQL within data pages, and the degree to which a page is targeted for filling at table creation or rewrite time is governed by the fillfactor storage parameter. When frequent updates affect a table, more space for placing a new row version on that same page is available to PostgreSQL if free space is left on each page.

Heap-Only Tuple updates are tied to that. According to the author, when the updated row remains on the same heap page and no new index entries are needed for the indexed columns, new index entries can be avoided by a HOT update, and index-related work during updates may thereby be reduced. A fillfactor of 90 was the target requested in the issue.

The implementation itself was deliberately small. The author created a post-deployment database migration using GitLab's migration framework, applying fillfactor=90 to both tables. The migration is marked with milestone '19.5' and defines both up and down methods, so the setting can be applied and reverted. The up method runs ALTER TABLE statements setting fillfactor=90 on each table; the down method resets the fillfactor on each.

The author notes that the migration can be validated by running bin/rake db:migrate:up with the version 20261006165253, after which the resulting PostgreSQL table options can be inspected to confirm the fillfactor was set correctly.

A significant part of the account concerns GitLab's contribution workflow for people outside the organisation. The author says GitLab provides a Community Fork workflow, and that they created a branch named 629994-lower-fillfactor-on-vulnerability-identifiers and pushed it to the GitLab Community Fork before opening a merge request against the main repository.

The merge request is identified in the post as !260121, titled "db: lower fillfactor on vulnerability identifier tables to 90," and was linked to issue #629994 so the relationship between implementation and original issue was clear. The author also says the merge request included instructions for validating the migration.

The most instructive section of the post covers what happened after the merge request was opened. GitLab automatically started CI pipelines to validate the contribution, and the author reports that the initial pipeline contained failures across several different jobs.

The author says, crucially, that the same shell error was shown by multiple unrelated jobs: "pop_var_context: head of shell_variables not a function context." Database setup jobs, migration-validation jobs, and other CI jobs all displayed that error. According to the author, no PostgreSQL error specifically tied to the migration, the two vulnerability tables, or the fillfactor setting was visible in the available logs.

From this, a general lesson is drawn by the author: contributed code is not automatically wrong just because a CI pipeline fails, and investigating the actual failure, rather than immediately changing working code, was the appropriate response. This interpretation comes from the author's own experience; it is not a verified diagnosis of the pipeline failure.

The post closes with a set of takeaways the author says they would not have gained from solving coding problems locally: read the issue before writing code, understand the technology behind the change, learn the project's established workflows, investigate CI failures rather than assuming the code is at fault, and accept that small changes can still require careful reasoning because database storage behaviour can have performance implications at scale.

For freelancers and developers who work on client codebases or contribute to upstream projects, the account is a concrete illustration of how much of a contribution sits outside the diff. The Ruby migration is a few lines; the surrounding work involved reading issue context, understanding PostgreSQL page storage, following a fork-and-merge-request convention, and interpreting CI output. That ratio is worth budgeting for when scoping open-source work or estimating a client task that touches a large, unfamiliar repository.

There are also tradeoffs visible in the account. Lowering fillfactor to 90 leaves more free space per page, which the author frames as helpful for frequently updated tables, but the post does not discuss the cost side in any detail, such as additional pages and storage for the same row count. The author does not present any before-and-after performance measurement of their own, so the expected benefit rests on the issue's reported HOT-update fractions rather than on results from this change.

Several things remain unknown. The author states that at the time of writing the merge request was still going through GitLab's normal review and CI process, so there is no confirmed outcome, no merge, and no release in which the change would appear. The cause of the shell error in the pipeline is not identified in the post. The author also does not say whether the CI failures were later resolved or whether the migration was revised.

The account should be read as one contributor's experience report. The issue number, merge request number, branch name, migration version and HOT-update percentages are all as stated by the author; none of them are corroborated by a second source in the supplied material, and the linked references do not independently support the same claims.

The practical value for this audience is procedural rather than technical novelty. The post documents a repeatable sequence for a first contribution to a large project: pick a well-defined issue, learn the project's contribution workflow, keep the change small, provide validation instructions in the merge request, and treat a red pipeline as a question to investigate rather than a verdict. The author's own summary is that the first contribution is the hardest part and that the process becomes more familiar afterwards.