Update in check_max_stack_depth
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253334psql -h localhost -U postgresBuilt from patchset v2 (message #2), August 25, 2026 at 12:46 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253334_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253334_2 && git checkout t253334_2Patchset v2 (message #2) is on t253334_2
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
--
С уважением,
Шанина Дарья Александровна
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:
/messages/by-id/CAM-w4HMwwcwaVvYcAH0_FGtG5GeXdYVRfvG81pXnSJWHnCfosQ@mail.gmail.com
Tom argued against shrinking STACK_DEPTH_SLOP just so startup would
succeed there:
/messages/by-id/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 100With 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
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:/messages/by-id/CAM-w4HMwwcwaVvYcAH0_FGtG5GeXdYVRfvG81pXnSJWHnCfosQ@mail.gmail.com
Tom argued against shrinking STACK_DEPTH_SLOP just so startup would
succeed there:/messages/by-id/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 100With 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
--
С уважением,
Шанина Дарья Александровна