[Suggestion] Apply simple validation to alter command

Abierto Apto para principiantes
  • ¿Algo no está bien?
#1,431 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 10 días

@drkemp187 ya está trabajando en esto.

Desde el 30/7/2026.

  • #1744 de @drkemp187 — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
64/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
go, mariadb
Área
database

Línea de trabajo

Comienza por el manejo del argumento de línea de comandos --alter de gh-ost y compara las dos formas de comando mostradas en el issue. Se considerará terminado cuando la forma que comienza con ALTER TABLE sea rechazada con un error claro, mientras que la cláusula alter sin más siga siendo aceptada; añade cobertura usando el punto de entrada de pruebas de validación existente del repositorio.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement good first issue

tl;dr: It would be nice if the --alter command line arg did some basic validation and threw an error if your SQL starts with ALTER TABLE as that can have unexpected results.

DB: Mariadb 10.6.10
gh-ost: 1.1.5

I ran into an interesting issue today that I think could be prevented with a little input validation in gh-ost. I was adding a modified_time column to an existing table with associated index and used the following flags in my gh-ost command:

gh-ost
    --table="exampletable"
    --alter="ALTER TABLE exampletable ADD COLUMN modified_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, ADD INDEX i_modified_time (modified_time);"

The command worked by all appearances: it created the new table, I verified that the column and index was created, and then executed the cutover. Shortly we discovered that the new table didn't have any actual data in its indexes, the Cardinality was 0 for all of them including PRIMARY, which made every query crawl. We ended up having to roll back the cutover, which ended up being fairly painful.

I'm not 100% sure why this happened as we've run gh-ost in production before (including the exact same migration of adding a modified_time column to a different table!) without issue, but it's 100% reproducible on this particular table on our database. Possibly related to https://github.com/github/gh-ost/issues/875 and/or https://jira.mariadb.org/browse/MDEV-28327?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel.

Running the same gh-ost command but dropping the ALTER TABLE exampletable from the --alter= flag works correctly, the created table has its indexes populated and the cutover works fine.

Ultimately this is user error, but given that it's an easy mistake to make (especially for someone new at gh-ost) and it's easy to catch, adding a check to the --alter to throw an error if you pass ALTER TABLE to it should be simple to implement and might save someone else a headache and some downtime in the future.

Lenguaje dominante
Go
Estrellas
13.6k
Forks
1.4k
Merge medio
9 d 19 h
PR fusionados (30 d)
1

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/gh-ost

Todos los issues de github/gh-ost

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.