?
本文檔使用 php中文網(wǎng)手冊 發(fā)布
以毫秒計的時間,用于設(shè)置在檢查是否存在死鎖條件之前等待的時間。 檢查是否存在死鎖條件是一個昂貴的過程,因此服務(wù)器不會在每次等待鎖的 時候都運行這個過程。我們(樂觀地)假設(shè)在生產(chǎn)應(yīng)用中的死鎖是不常出現(xiàn)的, 因此我們在開始詢問是否可以解鎖之前只等待一個相對較短的時間。增加這 個值就減少了浪費在無用的死鎖檢查上的時間,但是減慢了報告真正死鎖 錯誤的速度。缺省是 1000(1秒),這可能是你能夠耐心等待的最短時間 。在一個重負(fù)載的服務(wù)器上,你可能需要增大它。這個值的典型設(shè)置應(yīng)該 超過你的事務(wù)持續(xù)時間,這樣就可以減少在鎖釋放之前就開始死鎖檢查的問題。
當(dāng)設(shè)置了log_lock_waits參數(shù)時, 這個參數(shù)同時還可以決定發(fā)出關(guān)于鎖等待的日志等待時間。 如果想調(diào)查鎖時延,可以將參數(shù)設(shè)置小于deadlock_timeout的正常值。
共享的鎖表的大小是以假設(shè)任意時刻最多只有 max_locks_per_transaction* (max_connections+max_prepared_transactions) 個獨立的對象需要被鎖住 為基礎(chǔ)進(jìn)行計算的。所以,這個參數(shù)的名字可能有些讓人糊涂: 這not是單個事務(wù)可以使用的鎖數(shù)目的硬限制, 而是一個平均值。缺省值 64 ,已經(jīng)經(jīng)歷史證明是足夠的了, 不過如果你的客戶可能在一個事務(wù)里面修改很多不同的表,那么你就 可能需要提高這個數(shù)值。這個值只能在服務(wù)器啟動的時候設(shè)置。
增大這個參數(shù)可能導(dǎo)致PostgreSQL要求更多的 System V共享內(nèi)存,可能超過操作系統(tǒng) 的缺省配置。必要時,參閱節(jié)Section 17.4.1獲取如何 調(diào)節(jié)這些參數(shù)的信息。
當(dāng)在一個備庫運行時,這個參數(shù)的值必須大于等于主庫上的值,否則,備庫上不能執(zhí)行查詢操作。