PostgreSQL：CURRENT_TIMESTAMP和CLOCK_TIMESTAMP解決方案：Windows與Linux？

所以我對PostgreSQL定時函數有這個有趣的問題。PostgreSQL：CURRENT_TIMESTAMP和CLOCK_TIMESTAMP解決方案：Windows與Linux？

這是情況。我們有一個預生產服務器（Linux），我們擁有我們的開發應用程序。我還會在該數據庫（Windows）的本地副本上做一些工作，以防服務器上出現一些更重要的工作。我最近遇到了一個問題，我開始在本地數據庫副本上的日誌記錄表上獲取主鍵違例。我認爲這是不可能的，因爲我使用CLOCK_TIMESTAMP（當前系統時間）作爲主鍵。另外，我在pre-prod服務器上進行了測試，並且它工作正常。所以我做了一些調查。我最終發現，如果我在服務器上運行'SELECT CLOCK_TIMESTAMP（）'，它會將時間返回到微秒。如果我在本地主機上運行它，它只會下降到毫秒。所以如果在計時器到達下一毫秒之前發生多次更新，就會出現這個問題，這對於我們的一些進程是絕對有可能的。

所以我的問題是這樣的。爲什麼會發生這種情況，我該如何解決？這是我一直無法找到的一些模糊的設置嗎？或者在Windows和Linux的定時器分辨率上有所不同？

編輯：同樣的事情發生在CURRENT_TIMESTAMP，NOW（）和所有其他時間戳返回的內置函數中。

感謝

來源

2013-11-04 Bat Masterson

當你鍵入'select now（）:: timestamp（6）;'時，在Windows上會發生什麼？ –

@Denis 'select now（）:: timestamp（6）;'returns'2013-11-04 15:43：08.896' –

這個pg_hackers螺紋報價湯姆巷：

http://www.postgresql.org/message-id/[email protected]

我想你實際上問的是不是數據類型的精度，但現在的精度（）讀數。你運氣不好--- Windows只是沒有公開一個呼叫，讓掛鐘時間比1毫秒更好的。

請記住，不管Linux機器返回的結果可能是，這在很大程度上也是低階位的幻想。

要解決您的問題，請考慮使用串行作爲主鍵。（當然，假設你實際上首先需要一個主鍵作爲日誌文件。）

來源

2013-11-04 20:53:59

啊哈，這就是答案。我認爲這是某種特定操作系統。你說得對，我們可能不應該把它當作關鍵。我認爲我們最初是這樣做的，所以我們可以在日期內快速查詢，但索引也可以。非常感謝！ –

PostgreSQL：CURRENT_TIMESTAMP和CLOCK_TIMESTAMP解決方案：Windows與Linux？

回答

相關問題