Re: Update in check_max_stack_depth

Поиск
Список
Период
Сортировка
Искать

Re: Update in check_max_stack_depth

От:
Andrey Rachitskiy <pl0h0yp1@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.


чт, 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

Re: Update in check_max_stack_depth

От:
Daria Shanina <vilensipkdm@gmail.com>
Дата:
Hi, Andrey!
It`s very interesting discoveries. Thank you for your patch - it`s is more precise. I will use him!

Best regards,
Daria Shanina

чт, 6 авг. 2026 г. в 17:22, Andrey Rachitskiy <pl0h0yp1@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.


чт, 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


--
С уважением,
Шанина Дарья Александровна
FAQ