首先，非常感谢！在容器内手动停止服务似乎奏效了，我得以完成了升级所需的双容器重建（如上所述调整了 locale 变量——题外话：我查看了安装文档，似乎没有提到 locale；这或许可以添加进去）。
不幸的是，对问题进程的分析尚无定论。我只看到与 Postgres 相关的东西，比如 WalWriter、AutoVacuum 等。我唯一线索是，当我重启系统时，以及在更新期间进行索引更改后，我通常会看到 Postgres 的 CPU 负载在半小时左右很高。
今天重启后，当我检查 pg_stat_activity 时，我看到了两个长时间运行的查询（至少如果我对列的理解是正确的话）：
SELECT "posts"."id" FROM "posts" INNER JOIN "topics" ON "topics"."deleted_at" IS NULL AND "topics"."id" = "posts"."topic_id" LEFT JOIN post_search_data ON post_id = posts.id WHERE "posts"."deleted_at" IS NULL AND (posts.raw != '') AND (topics.deleted_at IS NULL) AND (post_search_data.locale IS NULL OR post_search_data.locale != 'de' OR post_search_data.version != 5) ORDER BY posts.id DESC LIMIT 20000
和
SELECT "optimized_images".* FROM "optimized_images" WHERE "optimized_images"."upload_id" = 13 AND "optimized_images"."height" = 32 AND "optimized_images"."width" = 32 LIMIT 1
在上述 30 分钟后，第一个查询显然已完成，Postgres 的 CPU 负载现在正常。
我不确定为什么这两个查询会花费这么长时间，更不确定为什么第二个查询在超过一个小时后仍然显示在 pg_stat_activity 中，但可能正是这种长时间运行的查询阻止了 Postgres 服务在之前尝试重建时正确关闭。
如果您有任何线索，将不胜感激。但这可能也需要另开一个帖子讨论（如果是这样，请告诉我，我会编辑此帖）。
相关截图：
