Tenía un índice único en unas tablas de Postgres y en una migración que tenemos que hacer el pg restore fallaba diciendo que no había unicidad en ciertas tablas.

Yo diciéndole al otro cabro que tal vez que habría fallado, que RDS estaba weando, que tal vez habían inserts posteriores que rompieron todo, que tal vez las tablas tenían un índice concurrente inválido… en fin.

El error solo estaba en 2 tablas, una con 2 problemas y otra solo con una. Los índices de unicidad estaban creados desde el inicio. La migración no dejaba de fallar.

Si uno buscaba en la tabla original por la key no aparecian todas las ocurrencias (ya que se usaba en índice), pero al buscar por los id’s que si estaban repetidos o haciendo un count(*) conun HAVING >1 para ver que se repetía, las filas con problemas si aparecían.

En la base original hicimos un reíndex y falló, diciendo que una llave violaba la unicidad. Postgres mismo me estaba diciendo que no podía crear un índice único donde tenía un índice único.

Las filas con problemas fueron arregladas (dejamos solo la primera en ser insertada) y los índices reconstruidos. pg restore no tiró ni un drama.

¿Qué falló? No tengo idea. No sé me ocurre nada que podría haber provocado que el índice no se respetara.

Buscando en internet siempre son fallos de diseño la falta de unicidad, pero acá no era el caso. Pillé una pregunta donde hablaban como una cadena de strings tenía caracteres que no se veían pero si contaban los bytes, haciendo que octet_length() diera resultados diferentes. Lamentablemente no pudimos probar eso porque las filas malas ya estaban eliminadas, y aunque tenemos un backup, este tirará el error de duplicidad que nos ha estado dado al restaurar. Si había un carácter extra, por qué pg_dump y pg_restore no los respetaban? Eso tampoco cuadraba.

¿Tal vez fue un rayo cósmico? , quien sabe. El misterio quedará sin resolver.