{"Entry":{"collection":"guc","key":"max_stack_depth","name":"max_stack_depth","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Resource Usage / Memory","category_zh":"","changed_in":[],"changes":[{"documentation_changed":false,"fields":{},"from":"7.4","status":"added","to":"8.0"},{"documentation_changed":true,"fields":{},"from":"8.1","status":"changed","to":"8.2"},{"documentation_changed":true,"fields":{},"from":"8.2","status":"changed","to":"8.3"},{"documentation_changed":true,"fields":{},"from":"8.4","status":"changed","to":"9.0"},{"documentation_changed":true,"fields":{},"from":"11","status":"changed","to":"12"},{"documentation_changed":true,"fields":{},"from":"14","status":"changed","to":"15"}],"content_hash":"31ca6f8bcf38533ed30abfa02a7ecac5b0f09098c1f9bffd1b690a93774e219c","context":"","default_changed_in":[],"default_history":[{"from":"9.0","to":"19","value":"100 KiB"}],"derived_content_hash":"71c2af198c2fc3e0976e1364125ce62c1188b93ce978373fafedaaf74d3da8f4","editorial":{"advice":{"olap":"Query duration, table size, and bulk I/O do not justify a larger stack ceiling. Change it only for verified deep expression or function recursion, and test backend stability with the same OS service limits used in production.","oltp":"Keep the effective 2MB default unless a reproducible recursive function or expression reaches the PostgreSQL guard. Before raising it, record the service's real kernel stack limit and preserve about 1MB of safety margin.","small":"Do not lower or raise it merely to save memory: the value is a safety check, not reserved memory. Keep the configured default unless the kernel stack and a specific recursive workload prove another value safe and necessary."},"mechanism":["max_stack_depth is a guard used by selected recursive execution paths. It neither allocates a process stack nor changes the operating-system stack limit; the kernel limit remains authoritative.","The catalog's raw boot_val is 100kB in every measured PG9.0–19 Beta 3 image, but the same fresh containers report setting=2048kB, matching the documented 2MB default after configuration/initdb. The 100kB boot fallback must not be presented as the ordinary effective setting.","A safe explicit value is the kernel stack limit, such as ulimit -s, minus roughly 1MB because not every C call site checks depth. Setting it above the real limit can let runaway recursion crash a backend. Its superuser context allows an authorized runtime change without a restart."],"pitfalls":["Confusing boot_val=100kB with the measured and documented effective setting of 2048kB.","Treating max_stack_depth as allocated memory or a way to reduce resident memory.","Setting it above the kernel stack limit and allowing recursive code to crash a backend.","Copying a value across hosts without checking the service manager and ulimit stack settings."],"references":[{"title":"PostgreSQL 19 Beta 4: max_stack_depth","url":"https://www.postgresql.org/docs/19/runtime-config-resource.html#GUC-MAX-STACK-DEPTH"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["max_worker_processes","shared_buffers","work_mem","max_connections"],"summary":"max_stack_depth — Sets the maximum stack depth, in kilobytes. Observed in PG9.0–19 Beta 4; its last measured boot default is 100 KiB in PG19 Beta 4, with superuser context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"8.0","group":"Resource Usage","group_slug":"resource","imported_at":"2026-09-27T17:57:31.742688+08:00","intro_commit":{},"key":"max_stack_depth","last_version":"20","max_val":"","min_val":"","name":"max_stack_depth","position":284,"present_in":["8.0","8.1","8.2","8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6","10","11","12","13","14","15","16","17","18","19","20"],"repair_provenance":{"original_source_revision":"english-manuals:ac88abf1b6a465c047bf42f2f3e776fd369e84e98d27d12d8753d92168d9d21d","receipt_sha256":"00fe125cfabbea7ad975900aade8de188d11482605d1607f5ed68e976b607877","repair":"wiki-repair-20261023"},"short_desc":"Specifies the maximum safe depth of the server's execution stack.","short_desc_zh":"","source_rev":"wiki-repair-20261023:5656e0497e423f77dbb219c3fdc64a74b6ed5b450a718fb0d7d12852d9ade214","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"max_stack_depth","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"max_stack_depth","SourceRevision":"wiki-repair-20261023:5656e0497e423f77dbb219c3fdc64a74b6ed5b450a718fb0d7d12852d9ade214","Facts":{"boot_val":"100","category":"Resource Usage / Memory","context":"superuser","description":"Specifies the maximum safe depth of the server's execution stack. The ideal setting for this parameter is the actual stack size limit enforced by the kernel (as set by ulimit -s or local equivalent), less a safety margin of a megabyte or so. The safety margin is needed because the stack depth is not checked in every routine in the server, but only in key potentially-recursive routines. If this value is specified without units, it is taken as kilobytes. The default setting is two megabytes (2MB), which is conservatively small and unlikely to risk crashes. However, it might be too small to allow execution of complex functions. Only superusers and users with the appropriate SET privilege can change this setting. 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, the server will not allow this variable to be set to an unsafe value. However, not all platforms provide the information, so caution is recommended in selecting a value.","description_zh":"指定服务器执行栈的最大安全深度。此参数的理想设置是由内核强制执行的实际栈大小限制（如由 ulimit -s 或本地等效设置），减去大约一兆字节的安全余量。需要安全余量是因为服务器中并非每个例程都检查栈深度，而只在关键的潜在递归例程中检查。如果未指定单位，则将其视为千字节。默认设置为两兆字节（2MB），这是保守且不太可能引起崩溃的小值。但是，这可能太小，无法执行复杂函数。只有超级用户和具有适当 SET 权限的用户才能更改此设置。 把 max_stack_depth 参数设置得高于实际的内核限制将意味着一个失控的递归函数可能会导致一个独立的后端进程崩溃。在 PostgreSQL 能够检测内核限制的平台上，服务器将不允许把这个参数设置为一个不安全的值。不过，并非所有平台都能提供该信息，所以我们还是建议你在选择值时要小心。","description_zh_html":"\u003cp\u003e\n        指定服务器执行栈的最大安全深度。此参数的理想设置是由内核强制执行的实际栈大小限制（如由 \u003ccode class=\"literal\"\u003eulimit -s\u003c/code\u003e 或本地等效设置），减去大约一兆字节的安全余量。需要安全余量是因为服务器中并非每个例程都检查栈深度，而只在关键的潜在递归例程中检查。如果未指定单位，则将其视为千字节。默认设置为两兆字节（\u003ccode class=\"literal\"\u003e2MB\u003c/code\u003e），这是保守且不太可能引起崩溃的小值。但是，这可能太小，无法执行复杂函数。只有超级用户和具有适当 \u003ccode class=\"literal\"\u003eSET\u003c/code\u003e 权限的用户才能更改此设置。\n       \u003c/p\u003e\u003cp\u003e\n        把 \u003ccode class=\"varname\"\u003emax_stack_depth\u003c/code\u003e 参数设置得高于实际的内核限制将意味着一个失控的递归函数可能会导致一个独立的后端进程崩溃。在 \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 能够检测内核限制的平台上，服务器将不允许把这个参数设置为一个不安全的值。不过，并非所有平台都能提供该信息，所以我们还是建议你在选择值时要小心。\n       \u003c/p\u003e","doc":{"anchor":"GUC-MAX-STACK-DEPTH","file":"runtime-config-resource.html","lang":"en","sha256":"2e207c599f0884dfbe594558c478a2c7c132578981071e980e2015f31dfce28c","slug":"18"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":"2147483647","metadata_version":"18","min_val":"100","name":"max_stack_depth","short_desc":"Sets the maximum stack depth, in kilobytes.","source":"pg-settings-source-snapshot","translation_provenance":{"inputs":[{"kind":"current-pgdoc-translation","path":"/Users/vonng/pgsty/pgdoc/zh/18/html/runtime-config-resource.html","sha256":"f5fedbf88ec5f973aaf4e525c03e46dda2a2186dabee154e26780da96b2ac85a"}],"kind":"same-version-pgdoc","locale":"zh-Hans","source_revision":"b1b500221dbe5437cfca004d6b04d3f6e422765d","version":"18"},"unit":"kB","vartype":"integer","zh_from":"same-version-pgdoc"},"ManualEvidence":{"doc":{"anchor":"GUC-MAX-STACK-DEPTH","file":"runtime-config-resource.html","lang":"en","sha256":"2e207c599f0884dfbe594558c478a2c7c132578981071e980e2015f31dfce28c","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"max_stack_depth","SourceDatabase":"center","Version":"18","Locale":"en","Title":"max_stack_depth","Summary":"Specifies the maximum safe depth of the server's execution stack. The ideal setting for this parameter is the actual stack size limit enforced by the kernel (as set by ulimit -s or local equivalent), less a safety margin of a megabyte or so. The safety margin is needed because the stack depth is not checked in every routine in the server, but only in key potentially-recursive routines. If this value is specified without units, it is taken as kilobytes. The default setting is two megabytes (2MB), which is conservatively small and unlikely to risk crashes. However, it might be too small to allow execution of complex functions. Only superusers and users with the appropriate SET privilege can change this setting. 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, the server will not allow this variable to be set to an unsafe value. However, not all platforms provide the information, so caution is recommended in selecting a value.","BodyHTML":"\u003cp\u003eSpecifies the maximum safe depth of the server\u0026#39;s execution stack. The ideal setting for this parameter is the actual stack size limit enforced by the kernel (as set by ulimit -s or local equivalent), less a safety margin of a megabyte or so. The safety margin is needed because the stack depth is not checked in every routine in the server, but only in key potentially-recursive routines. If this value is specified without units, it is taken as kilobytes. The default setting is two megabytes (2MB), which is conservatively small and unlikely to risk crashes. However, it might be too small to allow execution of complex functions. Only superusers and users with the appropriate SET privilege can change this setting. 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, the server will not allow this variable to be set to an unsafe value. However, not all platforms provide the information, so caution is recommended in selecting a value.\u003c/p\u003e","SourceRevision":"wiki-repair-20261023:5656e0497e423f77dbb219c3fdc64a74b6ed5b450a718fb0d7d12852d9ade214","ContentHash":"dc9493253bffe7d2d2a6ff6be6619b8f11931cd0e5ac3586126154e40c6c3d97","Payload":{"description":"Specifies the maximum safe depth of the server's execution stack. The ideal setting for this parameter is the actual stack size limit enforced by the kernel (as set by ulimit -s or local equivalent), less a safety margin of a megabyte or so. The safety margin is needed because the stack depth is not checked in every routine in the server, but only in key potentially-recursive routines. If this value is specified without units, it is taken as kilobytes. The default setting is two megabytes (2MB), which is conservatively small and unlikely to risk crashes. However, it might be too small to allow execution of complex functions. Only superusers and users with the appropriate SET privilege can change this setting. 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, the server will not allow this variable to be set to an unsafe value. However, not all platforms provide the information, so caution is recommended in selecting a value."}},"RequestedLocale":"en","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","8.0","8.1","8.2","8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}