Re: Update in check_max_stack_depth

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.

чт, 6 авг. 2026 г. в 18:31, Daria Shanina <vilensipkdm(at)gmail(dot)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