Topic.reset_all_highest がディスクの全容量を使い果たす

バグ
1

SMF2フォーラムから20年以上の活動履歴を持つデータをインポートしたローカルコンテナで作業中に、Topic.reset_all_highest のショーストップバグに遭遇しました。
データインポート後、DBには約6万件の通常のトピックと約40万件のプライベートメッセージのトピックが表示され、Topic.reset_all_highest 内のクエリが何らかの幾何級数的な行数の増加を引き起こし、その結果ディスク容量が不足します（開始時には120GBの空き容量がありました）。
現在、クエリを管理可能なチャンクに分割し、Postgresで直接実行しようとしていますが、それはもちろん最適ではなく（そして、それが機能し、正しい結果をもたらすかどうかも定かではありません）、
他の誰かがこの種の問題を抱えているかどうかを確認しようとしましたが、何も見つからなかったので、これが私のセットアップに関連している可能性があるかどうか疑問に思っています。ちなみに、最新のDockerバージョンを使用しています。

「いいね！」 1
2

最近、適度なサイズのインポートを行ったのですが、Topic.reset_all_highest で無期限にハングアップしてしまい、Postgres でクエリを強制終了しないと続行できませんでした。以前はこの問題は発生しておらず、Postgres サーバーが過負荷になっているだけかと思っていました（多くのサイトが接続されています）。

次に別の Postgres サーバーに移行することを考えていますが、まだ実行できていません。

3

「分割クエリ」実験の最初の2つのビット（公開トピックのXとY）が順調に進んだ後、Zで試したところ、フリーズしました。つまり、PostgreSQLのアクティビティによるとクエリはアクティブであり、topはプロセスが100％で実行されていることを示していました。
そこでSQLを再度確認したところ、問題が見つかりました。両方のクエリは次のように終わっています。

      WHERE
        topics.archetype <> 'private_message' AND
        X.topic_id = topics.id AND
        Y.topic_id = topics.id AND
          (
          topics.highest_staff_post_number <> X.highest_post_number OR
          topics.highest_post_number <> Y.highest_post_number OR
          topics.last_posted_at <> Y.last_posted_at OR
          topics.posts_count <> Y.posts_count OR
          topics.word_count <> Z.word_count
        )

（もう一方はもちろん、アーキタイプが「private_message」です）
これは、クエリが欠落していることを意味します。
Z.topic_id = topics.id - これが全体的な幾何学的な増加を引き起こします。

クエリのWHERE句を次のように変更します。

      WHERE
        topics.archetype <> 'private_message' AND
        X.topic_id = topics.id AND
        Y.topic_id = topics.id AND
        Z.topic_id = topics.id AND
          (
          topics.highest_staff_post_number <> X.highest_post_number OR
          topics.highest_post_number <> Y.highest_post_number OR
          topics.last_posted_at <> Y.last_posted_at OR
          topics.posts_count <> Y.posts_count OR
          topics.word_count <> Z.word_count
        )

これにより、問題が解決しました。
PRを開くべきでしょうか？

「いいね！」 2
4

そう思います。もしそれが壊れたコミットを見つけられたなら、さらに説得力が増すでしょう。

「いいね！」 1
5

これに対するPRを開きましたが、残念ながらいくつかの制限があります（つまり、この変更をテストする方法を想像できません）。

「いいね！」 6
6

この変更は正しいように見えるので、マージします。

（テストの観点からは、カバレッジがあり、簡単なテストで十分であることを確認する必要があります。回帰がないことを確認するだけで十分です。）

「いいね！」 5