Contribuir a GitLab: del issue al merge request

En pocas palabras: Para contribuir a GitLab, el autor tomó el issue #629994, escribió una migración post-deployment que fija fillfactor=90 en dos tablas de vulnerabilidades, subió la rama al Community Fork y abrió el merge request !260121 contra el repositorio principal, vinculado al issue. Según el relato, el MR estaba en revisión; al 6 de octubre de 2026 no hay merge confirmado.

Para contribuir a GitLab como externo, el autor de un post en dev.to tomó el issue #629994, escribió una migración que baja el fillfactor a 90 en dos tablas de vulnerabilidades, subió la rama al Community Fork y abrió el merge request !260121. El relato lo describe en revisión; al 6 de octubre de 2026 no hay merge confirmado.

El fillfactor es un parámetro de almacenamiento de PostgreSQL que define cuánto de cada página de una tabla intenta llenar la base al crear o reescribir la tabla. Un HOT update (Heap-Only Tuple) es una optimización que evita crear nuevas entradas de índice cuando la fila actualizada cabe en la misma página y no cambian columnas indexadas. Bajar el fillfactor deja espacio para que eso pase.

¿Qué es el fillfactor en PostgreSQL y qué tiene que ver con los HOT updates?

El fillfactor le indica a PostgreSQL qué porcentaje de cada página llenar cuando crea o reescribe una tabla; el valor por defecto es 100, es decir, empaquetado completo, según la documentación de CREATE TABLE. Si lo bajás, queda espacio libre en la página y una actualización puede dejar la nueva versión de la fila ahí mismo, que es una de las dos condiciones de un HOT update.

Según la documentación de PostgreSQL sobre heap-only tuples (versión 18, la vigente en 2026), la optimización se da cuando:

• La actualización no toca columnas indexadas. No cuentan los índices de resumen; el único en el núcleo de PostgreSQL es BRIN.
• Hay espacio en la página de la fila vieja. Ahí entra el fillfactor.

Cuando se cumplen ambas, no hacen falta nuevas entradas de índice (los índices de resumen todavía pueden necesitar actualización) y las versiones intermedias de una fila actualizada varias veces se eliminan durante la operación normal, incluso en SELECTs, sin esperar a un vacuum periódico.

Un matiz que la documentación aclara: bajar el fillfactor aumenta la probabilidad de HOT updates, pero no es requisito. Si no lo tocás, igual ocurren porque las filas nuevas migran a páginas con espacio. Para medir cuántos HOT y no HOT tenés, la vista pg_stat_all_tables sirve. Más contexto en comparativa entre GitHub Actions, Jenkins y GitLab CI.

¿Qué cambia la migración de GitLab en las tablas de vulnerabilidades?

La migración pone fillfactor=90 en vulnerability_identifiers y vulnerability_occurrence_identifiers, las dos tablas del issue #629994, “Lower fillfactor on the vulnerability identifier tables”. Es una migración post-deployment sobre Gitlab::Database::Migration[2.3], con milestone ‘19.5’, y tiene métodos up y down para aplicar y revertir el cambio.

Los números de partida vienen del relato del autor, que cita las mediciones del issue: fracción de HOT updates de aproximadamente 32,0 % para vulnerability_identifiers y 64,2 % para vulnerability_occurrence_identifiers. No los verificamos contra el issue original, así que tomalos como lo que son: datos de segunda mano.

# frozen_string_literal: true

class LowerFillfactorOnVulnerabilityTables < Gitlab::Database::Migration[2.3]
 milestone '19.5'

 def up
 execute('ALTER TABLE vulnerability_identifiers SET (fillfactor=90)')
 execute('ALTER TABLE vulnerability_occurrence_identifiers SET (fillfactor=90)')
 end

 def down
 execute('ALTER TABLE vulnerability_identifiers RESET (fillfactor)')
 execute('ALTER TABLE vulnerability_occurrence_identifiers RESET (fillfactor)')
 end
end

Son cuatro sentencias (sí, en serio). El down con RESET vuelve el parámetro a su valor por defecto, que es lo prolijo para una migración reversible.

Una inferencia nuestra, que no está en el post: como la fuente describe el fillfactor como algo que rige al crear o reescribir la tabla, un ALTER TABLE ... SET probablemente no reacomode las páginas que ya están llenas hasta que haya una reescritura. Confirmalo en la documentación de ALTER TABLE antes de prometer mejoras.

¿Cómo contribuir a GitLab si soy contribuidor externo?

Según el relato, el recorrido fue elegir un issue apto para la comunidad, implementar el cambio, subir la rama al Community Fork de GitLab y abrir un merge request contra el repositorio principal, vinculado al issue. El post no detalla requisitos de acceso ni la guía formal, y no vamos a rellenar ese hueco con pasos inventados. Tema relacionado: desplegar NestJS sin downtime con PM2.

1. Elegí un issue acotado. El autor tomó el #629994, con mediciones incluidas en el propio issue.
2. Implementá el cambio. Acá fue una migración post-deployment de pocas líneas.
3. Creá la rama. La suya se llama 629994-lower-fillfactor-on-vulnerability-identifiers.
4. Subila al Community Fork. Es el flujo que GitLab da a quienes contribuyen desde afuera.
5. Abrí el merge request y vinculalo al issue. El MR es !260121, titulado “db: lower fillfactor on vulnerability identifier tables to 90”.
6. Dejá instrucciones de validación. Por ejemplo, bin/rake db:migrate:up VERSION=20261006165253 y después inspeccionar las opciones de la tabla en PostgreSQL para ver que el fillfactor quedó aplicado.

¿Qué es un merge request en GitLab y cómo se crea?

Un merge request (MR) es la propuesta para integrar una rama al repositorio principal. Se abre después de subir la rama, y es donde GitLab dispara los pipelines de CI y donde pasan la revisión y las aprobaciones. Para los requisitos exactos de tu contribución, leé la guía oficial de contribución del proyecto.

¿Qué hacer cuando falla el pipeline de CI en un merge request?

Leé el error real de cada job antes de modificar código que funciona. En el caso del post, el pipeline inicial falló en varios jobs sin relación entre sí con el mismo error de shell, pop_var_context: head of shell_variables not a function context, y los logs no mostraban ningún error de PostgreSQL ligado a la migración, a las tablas o al fillfactor.

Subís el MR, el pipeline arranca solo, se ponen en rojo el setup de base de datos, la validación de migraciones y un par de jobs más, todos con el mismo mensaje, y te agarra la tentación de retocar la migración “para que pase” cuando en los logs no hay una sola línea que hable de tu cambio.

La fuente no determina la causa raíz. Nosotros tampoco.

Criterio propuesto (nuestro, no del post): si el mismo error aparece en jobs que no tienen nada que ver con tu diff, tratalo primero como un problema probable del entorno y no del código. Antes de cambiar nada, buscá en los logs alguna línea que mencione tus archivos o tus tablas. Cubrimos ese tema en detalle en alianza de GitLab y Capgemini en DevSecOps.

¿El merge request ya fue aceptado? Qué está confirmado y qué no

Al 6 de octubre de 2026 no hay merge confirmado. Según el post, cuando el autor lo escribió el MR !260121 seguía en el proceso normal de revisión y CI de GitLab; el relato no informa novedades posteriores.

Confirmado por la fuente

• El MR existe y está vinculado al issue #629994.
• La migración fija fillfactor=90 en dos tablas y tiene reversión.
• El pipeline inicial falló con el mismo error de shell en jobs distintos.

No confirmado (al 6 de octubre de 2026)

• Merge. El relato no informa si se aprobó.
• Efecto medido. No hay mediciones posteriores de la fracción de HOT updates.
• Resolución del CI. No se sabe cómo terminó la falla de shell.
• Que 90 sea el valor correcto fuera de este caso. Es el objetivo que pedía el issue, nada más.

La fuente es el relato de un contribuidor individual, y un cambio de fillfactor puede tener implicancias de rendimiento a escala (lo dice el propio autor). Lo que estos datos autorizan es medir en tu base, no copiar el 90.

Ejemplo propuesto por nosotros, no ejecutado contra GitLab y no descrito en el post, para verificar un caso parecido en tu PostgreSQL:

SELECT relname, reloptions
FROM pg_class
WHERE relname IN ('mi_tabla_a', 'mi_tabla_b');

SELECT relname, n_tup_upd, n_tup_hot_upd,
 round(100.0 * n_tup_hot_upd / nullif(n_tup_upd, 0), 1) AS pct_hot
FROM pg_stat_all_tables
WHERE relname IN ('mi_tabla_a', 'mi_tabla_b');

Guardá el resultado antes del cambio y comparalo después de un período de tráfico real, mirando la diferencia entre ambas lecturas y no el acumulado total. Te puede servir nuestra cobertura de migrar tu CI/CD de GitLab a AWS.

Errores comunes al contribuir con un cambio de base de datos

• Reescribir código que funciona porque el CI está en rojo. Corrección: leé el log de cada job y fijate si el error menciona tu cambio.
• Dar por hecho que bajar el fillfactor garantiza HOT updates. Si la actualización toca una columna indexada, no hay HOT aunque sobre espacio, según la documentación de PostgreSQL. Corrección: revisá qué columnas actualiza tu aplicación.
• Evaluar el resultado con una sola lectura. Los contadores de pg_stat_all_tables acumulan, y una foto suelta no te dice si algo mejoró. Corrección: tomá una lectura antes y otra después.
• Abrir el MR sin cómo validarlo. Corrección: incluí el comando de migración y qué inspeccionar, como hizo el autor.

Preguntas Frecuentes

¿Cómo contribuir a GitLab si soy contribuidor externo?

Elegís un issue apto para la comunidad, creás una rama, la subís al Community Fork y abrís un merge request contra el repositorio principal, vinculado al issue. Así lo hizo el autor del post con el issue #629994 y el MR !260121. Para los requisitos formales, seguí la guía oficial de contribución de GitLab.

¿Qué es el fillfactor en PostgreSQL?

Es un parámetro de almacenamiento de tabla que define qué porcentaje de cada página busca llenar PostgreSQL al crear o reescribir la tabla. El valor por defecto es 100. Con 90, queda espacio libre en la página para ubicar nuevas versiones de las filas actualizadas.

¿Qué es un HOT update en PostgreSQL y por qué mejora las actualizaciones?

Es una actualización que evita crear nuevas entradas de índice. Ocurre cuando no se modifican columnas referenciadas por índices (sin contar los de resumen, como BRIN) y la página de la fila vieja tiene espacio. Así se reduce el trabajo asociado a los índices en cada update.

¿Qué es el Community Fork de GitLab?

Es el flujo de trabajo que GitLab da a quienes contribuyen desde afuera: subís tu rama a ese fork y después abrís el merge request contra el repositorio principal. El post no detalla cómo se consigue el acceso, así que eso hay que buscarlo en la documentación oficial de GitLab.

¿Qué significa que falle el pipeline de CI en mi merge request si mi código parece correcto?

Puede significar que la falla no viene de tu cambio. En el post, varios jobs sin relación fallaron con el mismo error de shell y los logs no mostraban un error de PostgreSQL ligado a la migración. Revisá el error real de cada job antes de tocar el código.

Conclusión

El caso muestra que un cambio de cuatro sentencias en Ruby exige entender páginas, fillfactor y HOT updates, y también el flujo de contribución: issue, rama, Community Fork, MR y CI. Lo que todavía no existe es el resultado: al 6 de octubre de 2026 no hay merge confirmado ni una medición posterior que diga si la fracción de HOT updates mejoró.

Si querés contribuir a GitLab, arrancá con un issue bien definido, dejá instrucciones de validación en el MR y, si el CI se pone en rojo, leé los logs antes de tocar nada. Y si querés aplicar la idea en tu propia base, medí antes y después con tus datos.

Fuentes

• PostgreSQL – Documentación oficial: Heap-Only Tuples (HOT)
• PostgreSQL – Documentación oficial: CREATE TABLE
• dev.to – My First GitLab Open Source Contribution: From Issue to Merge Request