Re: Update in check_max_stack_depth
От
Andrey Rachitskiy
Тема
Re: Update in check_max_stack_depth
Дата
Msg-id
CAB8bMis0c6EZnUW=u5tsx13ofGeCrmiEOc4waisU54shudA5Vg@mail.gmail.com
Список
Дерево обсуждения
Re: Update in check_max_stack_depth Andrey Rachitskiy <pl0h0yp1@gmail.com>
Re: Update in check_max_stack_depth Daria Shanina <vilensipkdm@gmail.com>
Hi, Daria!
Thanks for the report.
The diagnosis looks right: when stack_rlimit <= STACK_DEPTH_SLOP the
arithmetic in check_max_stack_depth() goes non-positive, and that
value is what gets printed.
A related case was discussed before for NetBSD defaults of
ulimit -s 512kB:
https://postgr.es/m/CAM-w4HMwwcwaVvYcAH0_FGtG5GeXdYVRfvG81pXnSJWHnCfosQ@mail.gmail.com
Tom argued against shrinking STACK_DEPTH_SLOP just so startup would
succeed there:
https://postgr.es/m/32729.1467734050@sss.pgh.pa.us
I agree with that. Relative to master we should not change the
policy: still reject the setting, and still refuse to start with such
a ulimit. Only the misleading DETAIL needs fixing.
Relative to the posted patch, v2 rewords that DETAIL a bit, and avoids
treating stack_rlimit == -1 as "too small". That value means the
platform limit is unknown, and master already skips the rlimit check
in that case. Catching -1 would reject every max_stack_depth setting
on platforms without a usable RLIMIT_STACK.
Thanks for the report.
The diagnosis looks right: when stack_rlimit <= STACK_DEPTH_SLOP the
arithmetic in check_max_stack_depth() goes non-positive, and that
value is what gets printed.
A related case was discussed before for NetBSD defaults of
ulimit -s 512kB:
https://postgr.es/m/CAM-w4HMwwcwaVvYcAH0_FGtG5GeXdYVRfvG81pXnSJWHnCfosQ@mail.gmail.com
Tom argued against shrinking STACK_DEPTH_SLOP just so startup would
succeed there:
https://postgr.es/m/32729.1467734050@sss.pgh.pa.us
I agree with that. Relative to master we should not change the
policy: still reject the setting, and still refuse to start with such
a ulimit. Only the misleading DETAIL needs fixing.
Relative to the posted patch, v2 rewords that DETAIL a bit, and avoids
treating stack_rlimit == -1 as "too small". That value means the
platform limit is unknown, and master already skips the rlimit check
in that case. Catching -1 would reject every max_stack_depth setting
on platforms without a usable RLIMIT_STACK.
чт, 6 авг. 2026 г. в 18:31, Daria Shanina <vilensipkdm@gmail.com>:
Hi all,
when I was testing the work in low-memory conditions, I setted ulimit -s 512 and received an error message:
LOG: invalid value for parameter "max_stack_depth": 100
DETAIL: "max_stack_depth" must not exceed 0kB.
HINT: Increase the platform's stack depth limit via "ulimit -s" or local equivalent.
FATAL: failed to initialize max_stack_depth to 100
With lower stack values, the figure was negative
DETAIL: "max_stack_depth" must not exceed -256kB at ulimit -s 256
It appears because stack_rlimit is less than or equal to STACK_DEPTH_SLOP, and I added a check. Could you take a look?
Best regards,
Daria Shanina--С уважением,Шанина Дарья Александровна
Regards,
Rachitskiy Andrey
Rachitskiy Andrey
В списке pgsql-bugs по дате отправления
От: Zexin Li
Дата:
