在業務開發中，通常因爲代碼不規範、中間件缺陷、DBA誤提交批量SQL等原因，會導致服務端連接一直存在、但是實際上並未在執行的情況，從而導致數據庫連接泄露。爲了防止這種異常情況積壓，lightdb中包含了多個參數用於控制超時相關的行爲：
- lock_timeout：控制多久拿不到鎖就自動超時並回滾事務
- idle_in_transaction_session_timeout：設置會話在進入事務塊（顯示BEGIN）後，一直未退出、也未在執行SQL後多久自動結束會話
- statement_timeout：設置語句執行最長多久，超過之後就自動超時
- idle_session_timeout：設置會話在沒有進入事務塊（顯示BEGIN），也沒有執行SQL後多久沒活動自動超時
lightdb@oradb=# set idle_session_timeout to 3; SET lightdb@oradb=# lightdb@oradb=# lightdb@oradb=# lightdb@oradb=# commit; FATAL: terminating connection due to idle-session timeout server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Succeeded.
lightdb@oradb=# show %idle%; name | setting | description -------------------------------------+---------+-------------------------------------------------------------------------------- idle_in_transaction_session_timeout | 0 | Sets the maximum allowed idle time between queries, when in a transaction. idle_session_timeout | 0 | Sets the maximum allowed idle time between queries, when not in a transaction. tcp_keepalives_idle | 300 | Time between issuing TCP keepalives. (3 rows) lightdb@oradb=# set idle_in_transaction_session_timeout to 3; SET lightdb@oradb=# begin; BEGIN lightdb@oradb=*# select 1; FATAL: terminating connection due to idle-in-transaction timeout server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Succeeded.
lightdb@oradb=# set statement_timeout = 10000; SET lightdb@oradb=# select pg_sleep(10) from pg_class ; ERROR: canceling statement due to statement timeout
詳細可見https://www.light-pg.com/docs/lightdb/current/runtime-config-client.html。