3

ですから、PostgreSQL のタイミング関数には興味深い問題があります。

これが状況です。開発中のアプリケーションを格納する本番前のサーバー (Linux) があります。また、サーバーでさらに重要な作業が行われている場合に備えて、その DB (Windows) のローカル コピーに対して作業を行います。最近、ローカル DB コピーのログ テーブルで主キー違反が発生するという問題に遭遇しました。CLOCK_TIMESTAMP (現在のシステム時刻) を主キーとして使用していたので、これは不可能だと思いました。さらに、本番前のサーバーでテストしたところ、問題なく動作しました。というわけで色々調べてみました。最終的に、サーバーで「SELECT CLOCK_TIMESTAMP()」を実行すると、時間がマイクロ秒まで返されることがわかりました。ローカルホストで実行すると、ミリ秒までしかかかりません。そのため、タイマーが次のミリ秒に到達する前に複数の更新が発生すると、問題が発生します。

だから私の質問はこれです。なぜこれが起こっているのですか、どうすれば修正できますか? これは、まだ見つけられていないあいまいな設定ですか？それとも、Windows と Linux のタイマー解像度の違いですか?

編集:CURRENT_TIMESTAMP、NOW()、およびその他すべてのタイムスタンプを返す組み込み関数でも同じことが起こります。

ありがとう

4

1 に答える 1

4

この pg_hackers スレッドでの Tom Lane の引用:

http://www.postgresql.org/message-id/9699.1262011789@sss.pgh.pa.us

あなたが本当に求めているのは、データ型の精度ではなく、now() の読み取り値の精度だと思います。あなたは運が悪いです --- Windows は、壁時計の時間を 1 ミリ秒よりも速くするための呼び出しを公開していません。

Linux マシンが返すものは何であれ、下位ビットも大部分がファンタジーである可能性があることに注意してください。

問題を解決するには、シリアルを主キーとして使用することを検討してください。(もちろん、最初にログ ファイルの主キーが実際に必要であると仮定します。)

于 2013-11-04T20:53:59.263 に答える