max_stack_depth

http://www.pgsqldb.org/pgsqldoc-8.1c/regress-evaluation.html 27.2.6. 堆棧深度不夠 如果 errors 測試導致在 select infinite_recurse() 命令的時候服務器崩潰，這就意味著平台對進程堆棧的限制小於 max_stack_depth 參數指出的值。我們可以通過在更高的堆棧限制的數值上運行 postmaster 繞開這個問題 （缺省的 max_stack_depth 下，建議數值是 4M）。 如果你無法這麼做，那麼另外一個方法是減少 max_stack_depth 的值。 http://www.pgsqldb.org/pgsqldoc-cvs/runtime-config-resource.html 17.4.1. 內存 max_stack_depth (integer) 聲明服務器的執行堆棧的最大安全深度。為此設置一個參數的原因是內核強制的實際堆棧尺寸（就是 ulimit -s 或者局部等效物的設置），小於一個安全的一兆字節左右的範圍。 需要這麼一個安全的界限是因為在服務器裡，並非所有過程都檢查了堆棧深度， 兒只是在可能遞規的過程，比如表達式計算這樣的過程裡面進行檢查。 把這個參數設置得大於實際的內核限制講意味著一個正在跑的遞歸函數可能會導致一個獨立服務器進程的崩潰。 缺省設置是 2048 KB （兩兆），這個值相對比較小，不容易導致崩潰。 但是，這個值可能太小了，以至於無法執行複雜的函數。 PostgreSQL 8.2.3 Documentation 補充說明 Setting max_stack_depth higher than the actual kernel limit will mean that a runaway recursive function can crash an individual backend process. On platforms where PostgreSQL can determine the kernel limit, it will not let you set this variable to an unsafe value. However, not all platforms provide the information, so caution is recommended in selecting a value. 8.2版 發行公告 http://www.postgresql.org/docs/8.2/interactive/release-8-2.html Prevent max_stack_depth from being set to unsafe values On platforms where we can determine the actual kernel stack depth limit (which is most), make sure that the initial default value of max_stack_depth is safe, and reject attempts to set it to unsafely large values.