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`とすれば「現在書き込み途中のトランザクション」が終わるまで待って処理を開始できる。しかし、それだと「トランザクションは開始したがまだ書き込み始めていない」トランザクションは漏れてしまう。
バッチごとに増えるカウンタを用意して、その値を各行に入れてもらう: バッチのために余分な列と処理が増える。
レコード書き込み側も協力して事前に別のロックを別のステートメントで明示的あるいは暗黙のうちに取るようにする: バッチのために余計な処理が必要になる。忘れられがち。
一定時間より前のレコードだけ処理対象にする: 現実的だけどきれいじゃないし、バッチに反映されるまで時間がかかる。
Published at
2023-10-19 12:53:16Event JSON
{
"id": "c76c205467dd7ef1baadc39df82704b848989b471290ed5f43e07cb2a10bfae7",
"pubkey": "2888961a564e080dfe35ad8fc6517b920d2fcd2b7830c73f7c3f9f2abae90ea9",
"created_at": 1697719996,
"kind": 1,
"tags": [],
"content": "PostgreSQLメモ: PostgreSQLでは、`statement_timestamp()`はロックを取得する前の時刻が返ってくる。正確にはクライアントからのコマンドメッセージの到着時刻と定められている。\nhttps://www.postgresql.org/docs/16/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT\n`clock_timestamp()`は、`INSERT INTO test (t) VALUES (clock_timestamp());`などとした場合はロックを取得した後の時刻が返ってくるけど、保障はされていないっぽい。\n\n\nやりたいのは前回のバッチ処理より後に作成されたレコードを取得して処理することで、`LOCK foo IN SHARE MODE`とすれば「現在書き込み途中のトランザクション」が終わるまで待って処理を開始できる。しかし、それだと「トランザクションは開始したがまだ書き込み始めていない」トランザクションは漏れてしまう。\n\nバッチごとに増えるカウンタを用意して、その値を各行に入れてもらう: バッチのために余分な列と処理が増える。\nレコード書き込み側も協力して事前に別のロックを別のステートメントで明示的あるいは暗黙のうちに取るようにする: バッチのために余計な処理が必要になる。忘れられがち。\n一定時間より前のレコードだけ処理対象にする: 現実的だけどきれいじゃないし、バッチに反映されるまで時間がかかる。",
"sig": "56c620f20253d03562240adbf85312fa86633e5b10763a97334d2a21c64cae18a533168eae221014e91126018763501f73f4047560cb39eb0b71ef67960647ea"
}