Não é possível restaurar devido a índices corrompidos (com algumas dicas sobre como lidar com índices corrompidos)

Este também tinha duas entradas onde ‘shiny-server’ correspondia a apenas uma, mas ‘%hiney-server’ correspondia a ambas. Não vejo como isso me ajuda a entender, mas acho que você está dizendo que o select que estou fazendo espera que apenas um resultado seja retornado e o busca no índice, ignorando o outro, mas quando uso o %, ele pesquisa nos campos.

discourse=> EXPLAIN ANALYZE select * from tags where name='shiny-server'; 
                                                        QUERY PLAN                                                        
--------------------------------------------------------------------------------------------------------------------------
 Index Scan using index_tags_on_name on tags  (cost=0.28..8.29 rows=1 width=36) (actual time=0.038..0.040 rows=1 loops=1)
   Index Cond: ((name)::text = 'shiny-server'::text)
 Planning time: 0.129 ms
 Execution time: 0.070 ms
(4 rows)

Duvido bastante que alguém que não conseguiria descobrir isso por conta própria ache isso útil, mas… Fiz uma série de buscas pelos dois tag_ids com o mesmo nome e executei operações como:

 TopicTag.where(tag_id: 717).update_all(tag_id: 611)
 Tag.ensure_consistency!
 Tag.find(717) # garantir que não esteja em nenhum tópico
 Tag.find(717).destroy

e depois executei um reindex table tags; no psql.

E parece que agora precisarei fazer algo semelhante para users, como @bartv descreveu. Embora, com meus usuários, eu veja um usuário David e outro usuário david, além de [Mm]ark.

Aqueles eu corrigi assim:

marks=User.where("username similar to  '[Mm]+ark'").pluck(:id,:username,:created_at)

Depois, encontrei o novo Mark em /admin/users e renomeei o usuário ali. Em seguida, tentei executar reindex table users; no psql. (sudo su - discourse e depois psql).