| From: | Daria Shanina <vilensipkdm(at)gmail(dot)com> |
|---|---|
| To: | Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Update in check_max_stack_depth |
| Date: | 2026-08-07 09:41:54 |
| Message-ID: | CAMp4U1drw55S5KGAEXvOkcDQBVtsw8toKt++=8F=iRmukC+7_g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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(at)gmail(dot)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(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
>
--
С уважением,
Шанина Дарья Александровна
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2026-08-07 13:32:09 | BUG #19612: SEGV in ParseConfigFp() in guc-file.l |
| Previous Message | Daniel Gustafsson | 2026-08-07 08:41:21 | Re: BUG #19610: Database won't start if an unrelated process is exist |