Obrigado, pessoal! Corrigi a chave duplicada, removi os índices obsoletos e, em seguida, executei com sucesso:
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
O uso da CPU voltou ao normal. Ufa.
Pergunta: Por que um banco de dados não otimizado ou um índice corrompido levam a um uso tão alto de CPU pelo postmaster? Apenas por curiosidade.
Acho que o índice corrompido é uma pista falsa; certamente não é ideal e deve ser corrigido.
O grande problema é que essa migração da versão 10 para a 12 deixa o banco de dados com estatísticas ruins, o que resulta em desempenho inadequado.
O desempenho é ruim porque o otimizador de consultas escolhe planos muito ruins para as consultas, já que as estatísticas que ele possui sobre os dados nas tabelas estão totalmente equivocadas.
Vamos integrar a reconstrução das estatísticas via vacuum à nossa migração automatizada.
Obrigado, @sam, pelas explicações. Isso faz sentido. Acho que é uma boa ideia integrar a reconstrução à movimentação automatizada. Obrigado novamente pela sua ajuda!