おさ @[email protected]

対象件数がめっちゃ多い変更処理なんかは、分割できる範囲で少しずつ数万件毎にコミット入れたりするのも有用

1.処理の指示（クエリー）を受ける
2.WALに書き込む
3.実際のデータファイルに対して処理を行う
4.処理が終わってデータファイルの状態が確定する
5.WALを消す
という流れ。3でクラッシュしたり急に電源が切れたりしても、書き込み前時点からWALをやり直したら復活できる。あとWALを他のマシンに送ったら、バックアップしたりサーバ並列で立てられるよね。他にWALのやり直しを途中で止めたら好きな時間のDB再現できるのでは、という感じのところがWALの機能。なので、WALは処理順が重要で、確定しない処理が動いている限り削除できない。

WAL、結局DBに対する操作履歴なので、時間がかかるクエリーが流れているあいだはデータベースのファイルに対する処理が確定せず、履歴が消せないからどんどん膨らむ。

うちのサーバだと50分前より古いWALは無いな。なんかロングセッションが開いていると、その間処理内容が確定しないのでWALが消せないという事態が発生する。

wal_archive、普通はガンガン消えていくものでは。

ときどき他人のご飯が混ざるの好き。

word2vec、面白そうと思ってるだけで何も試していない。

今月前半の、税金と国保と車検と急に壊れたディスプレイ代の請求が一気に来たのは心停止した。

駅のトイレの壁に分散SNSアカウントが!?

スパシーバ

pg_stop_backupを実行したあとなら、pg_start_backupより前のWALは全消しして良かったはず。

雷

バックアップの完了がうまく処理出来なくてWALがガンガン増えるの、使い始めたころよくやった。

DBそんなに食うんかな。なんかログ消せてないとか。

マグロが寝ないのは本当か、なぜ寝ないのか知りたい。 | レファレンス協同データベース
http://crd.ndl.go.jp/reference/modules/d3ndlcrdentry/index.php?page=ref_view&id=1000164727