Re: Checking max_stack_depth automatically

I have just realized that getrlimit(RLIMIT_STACK) is a pretty widely
available syscall --- it's specified by the Single Unix Spec and the
man pages claim it works on all the platforms I have handy to check.
I propose that we make use of this call where available to prevent
people from setting max_stack_depth larger than, say, the current
stack rlimit less half a megabyte. This will prevent pilot error
such as here:
http://archives.postgresql.org/pgsql-bugs/2006-10/msg00053.php

It'd be even nicer to not have a max_stack_depth GUC at all, but
it's probably untenable to assume that getrlimit is available on
every platform.

Thoughts?

regards, tom lane

I wrote:
> I have just realized that getrlimit(RLIMIT_STACK) is a pretty widely
> available syscall --- it's specified by the Single Unix Spec and the
> man pages claim it works on all the platforms I have handy to check.
> I propose that we make use of this call where available to prevent
> people from setting max_stack_depth larger than, say, the current
> stack rlimit less half a megabyte.

I've committed changes along this line, and am now wondering whether
there isn't some equivalent to getrlimit(RLIMIT_STACK) on Windows
(I somehow doubt that the syscall exists as such ;-)). If someone
can provide a patch to postgres.c's new get_stack_depth_rlimit()
function, please do.

regards, tom lane

> > I have just realized that getrlimit(RLIMIT_STACK) is a
> pretty widely
> > available syscall --- it's specified by the Single Unix
> Spec and the
> > man pages claim it works on all the platforms I have handy to check.
> > I propose that we make use of this call where available to prevent
> > people from setting max_stack_depth larger than, say, the current
> > stack rlimit less half a megabyte.
>
> I've committed changes along this line, and am now wondering
> whether there isn't some equivalent to
> getrlimit(RLIMIT_STACK) on Windows (I somehow doubt that the
> syscall exists as such ;-)). If someone can provide a patch
> to postgres.c's new get_stack_depth_rlimit() function, please do.

It doesn't. It doesn't have the concept of RLIMIT, really.
In "the old days", there was on way to limit how much memory a process
uses. In Windows 2000, "Job Objects" were added, which can limit them.
But they make no difference between stack and non-stack memory.

For win32, we set the stacksize in src/backend/Makefile with
"-Wl,--stack=4194304". So we know at build time what it is, if that
helps you...

//Magnus

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> For win32, we set the stacksize in src/backend/Makefile with
> "-Wl,--stack=4194304". So we know at build time what it is, if that
> helps you...

Well, I can just wire that value into get_stack_depth_rlimit, I suppose,
but it sounds crocky. There's no way to tell at runtime what value was
set?

regards, tom lane

> > For win32, we set the stacksize in src/backend/Makefile with
> > "-Wl,--stack=4194304". So we know at build time what it is, if that
> > helps you...
>
> Well, I can just wire that value into get_stack_depth_rlimit,
> I suppose, but it sounds crocky.

If we do, we probably move it to a define (which could just be in the
Makefile) so we don't accidenally change one without the other, no?

> There's no way to tell at runtime what value was set?

None that I know of, and none that I can find in a quick search of the
API docs. A google shows up a couple of references to other people
saying it can't be done. (Other than opening your own EXE file and
manually parsing the PE header, but that seems at least as bad..) For
example, see the discussion aobut stack attributes at
http://www.roguewave.com/support/docs/hppdocs///thr200pl/8-2.html.

//Magnus

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
>> Well, I can just wire that value into get_stack_depth_rlimit,
>> I suppose, but it sounds crocky.

> If we do, we probably move it to a define (which could just be in the
> Makefile) so we don't accidenally change one without the other, no?

I think we'd have to put the define in Makefile.global, which seems like
overkill ... but OTOH, seeing that it's textually in two places in
backend/Makefile already, maybe that's the best way. The alternative is
to stick a comment in each place referencing the other(s) ...

>> There's no way to tell at runtime what value was set?

> None that I know of, and none that I can find in a quick search of the
> API docs. A google shows up a couple of references to other people
> saying it can't be done. (Other than opening your own EXE file and
> manually parsing the PE header, but that seems at least as bad..)

I agree, that's right out. Hardwired it shall be.

regards, tom lane

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
>>> For win32, we set the stacksize in src/backend/Makefile with
>>> "-Wl,--stack=4194304". So we know at build time what it is, if that
>>> helps you...
>>
>> Well, I can just wire that value into get_stack_depth_rlimit,
>> I suppose, but it sounds crocky.

> If we do, we probably move it to a define (which could just be in the
> Makefile) so we don't accidenally change one without the other, no?

OK, I've committed changes along these lines, but I can't really test
it. Next time you make a Windows build, would you please verify that
it still defaults to max_stack_depth = 2MB, and that it will let you set
max_stack_depth no higher than 3.5MB ?

regards, tom lane