prune_objects で使えなくなるの、引っ越し失敗なんだろうけど prune_objects 使わなかったら全然支障ないんだよな。前の環境で動いてたのがちょっと信じられないprune_objectsのオプション、crontab -e で変更したけど systemd にはちゃんと反映されてなくて実行されてなかったとかあるのかしら

語としては最大公約数でなくても使える？倍分の対の語としても挙げられてるし

約分（やくぶん）とは？ 意味・読み方・使い方をわかりやすく解説 - goo国語辞書
https://dictionary.goo.ne.jp/word/%E7%B4%84%E5%88%86/

まぁどうせリモートのものだしあんま困らんか

もしかしてバックアップが不完全だったり

逆に今までなんでこれ実行してきたのに平気だったんだろう

prune_objects、--keep-threads 有効にするとダルめの left outer join 使ったサブクエリが走って厳しい感がある

OCIのmetricsみたらちょうど3時間前に急にIOが跳ね上がってCPUもめっちゃ使ってたしDBのバックアップされてるからcronがJSTじゃなくてUTCで動いた結果かしら

Createをちゃんと受け取れてなかったから再起動の後にリプライが来たと思ったけどAnnounceとLikeしか処理されてない期間のNoteは残ってないので何もわからん

3時間前から後の投稿がひとつも取れてないから壊れたのHTLじゃない？

reblogしか見えないのpleroma側の問題な気もしてきたが引っ越しのときにimageを同時に更新してるので切り分けできてない

HTLが壊れてる

Ubuntu 20.04 から 24.04 への引っ越しの副作用じゃないけど、20.04では提供されてなかった aarch64 minimal になったので少々余裕がある

Splash screen (!1940) · マージリクエスト · Pleroma / pleroma-fe · GitLab
https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1940

すぐに投稿入力欄に触れられないからむしろストレスだが？？？みたいな気持ちになるな

なんかpleroma-feにスプラッシュスクリーンが追加されてる

pg_dump & pg_restore の実質 VACUUM FULL でpostgresのデータボリュームが12GBも小さくなっててすごいなぁつってる

2時半から始めたのでちょうど2時間半かかったけど、3時までは503返してる裏でpleromaのコンテナを止めてcrontabを移行して/var/lib/pleromaを持ってくるとかやって3時のcronでpg_dumpを10分ほど待ってからpg_restoreで1時間強放置だったので、移行の確認作業は30分から1時間かしら

引越し完了かしら

database prune_objects も終わってるし503返すようにして3時のpg_dump終わるの待ってpg_restoreかけるか