前回 、Oracleのトランザクションガードについて見てみました。 せっかくなので、というか単純に興味があったのでPostgreSQLのCOMMITの動きやOracleと同じく障害発生のタイミングによりトランザクションが行方不明になった時の対処方法を見てみたいと思います。 PostgreSQLのCOMMITの様子 とてもざっくりですが、PostgreSQLのCOMMITの様子を見てみます。 PostgreSQL 11のcommitの動き psqlなどクライアントは"COMMIT"という文字列をsendto(2)でbackendのソケットに書き込みます クライアントからのI/Oイベントにより起床したbackendは以下の処理を行います recvfrom(2)で"COMMIT"を受け取る write(2)でWALファイルにlog bufferの内容を書き出す write(2)でWALに書き出した後backendは以下の処理を行います fdatasync(2)でファイルシステムのキャッシュにあるデータを物理デバイスと同期させる sendto(2)によりクライアントにCOMMIT完了のメッセージを送信 recvfrom(2)でメッセージを受け取ったクライアントは最終的にCOMMIT完了の処理を実施(psqlの場合はコンソールに"COMMIT"を書き出す) 余談 ちなみに、PostgreSQLにwalwriterというプロセスがいますが"COMMIT"に限定すると通常のwalwriterはその名前から想像できるようなWALファイルへの書き込みを実行しません。walwriterは5秒おき(*)にlog bufferの内容をコミットの有無に関係なくWALファイルに書き込みを実施しますがCOMMIT時の同期書き込みはbackendが実施しています。しかし、トランザクションが非同期コミットとして設定される場合(synchronous_commit=offの場合)では、backendに送られたCOMMITをトリガーにCOMMIT自体のWAL recordがwalwriterにより非同期、バッチ的にWALファイルに書き込まれます。 5秒(wal_w...