ruto on Nostr: PostgreSQLメモ: ...
PostgreSQLメモ: PostgreSQLでは、`statement_timestamp()`はロックを取得する前の時刻が返ってくる。正確にはクライアントからのコマンドメッセージの到着時刻と定められている。
https://www.postgresql.org/docs/16/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT
`clock_timestamp()`は、`INSERT INTO test (t) VALUES (clock_timestamp());`などとした場合はロックを取得した後の時刻が返ってくるけど、保障はされていないっぽい。
やりたいのは前回のバッチ処理より後に作成されたレコードを取得して処理することで、`LOCK foo IN SHARE MODE`とすれば「現在書き込み途中のトランザクション」が終わるまで待って処理を開始できる。しかし、それだと「トランザクションは開始したがまだ書き込み始めていない」トランザクションは漏れてしまう。
バッチごとに増えるカウンタを用意して、その値を各行に入れてもらう: バッチのために余分な列と処理が増える。
レコード書き込み側も協力して事前に別のロックを別のステートメントで明示的あるいは暗黙のうちに取るようにする: バッチのために余計な処理が必要になる。忘れられがち。
一定時間より前のレコードだけ処理対象にする: 現実的だけどきれいじゃないし、バッチに反映されるまで時間がかかる。
https://www.postgresql.org/docs/16/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT
`clock_timestamp()`は、`INSERT INTO test (t) VALUES (clock_timestamp());`などとした場合はロックを取得した後の時刻が返ってくるけど、保障はされていないっぽい。
やりたいのは前回のバッチ処理より後に作成されたレコードを取得して処理することで、`LOCK foo IN SHARE MODE`とすれば「現在書き込み途中のトランザクション」が終わるまで待って処理を開始できる。しかし、それだと「トランザクションは開始したがまだ書き込み始めていない」トランザクションは漏れてしまう。
バッチごとに増えるカウンタを用意して、その値を各行に入れてもらう: バッチのために余分な列と処理が増える。
レコード書き込み側も協力して事前に別のロックを別のステートメントで明示的あるいは暗黙のうちに取るようにする: バッチのために余計な処理が必要になる。忘れられがち。
一定時間より前のレコードだけ処理対象にする: 現実的だけどきれいじゃないし、バッチに反映されるまで時間がかかる。