Re: Update in check_max_stack_depth

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
>

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

In response to

Browse pgsql-bugs by date

  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