Hi,
On 2020-04-05 14:33:19 -0400, Tom Lane wrote:
> It's a bit surprising perhaps that we run out of stack here and not
> somewhere else; but ParseFuncOrColumn and its subroutines consume
> quite a lot of stack, because of FUNC_MAX_ARGS-sized local arrays,
> so it's not *that* surprising.
>
> So, what to do to re-stabilize the regression tests? Even if
> we wanted to revert 8f59f6b9c0, that'd be kind of a band-aid fix,
> because there are lots of other possible ways that a parser error
> callback could be active at the point of the error. A few other
> possibilities are:
>
> 1. Change the test to do "\set VERBOSITY sqlstate" so that all that
> is printed is
> ERROR: 54001
> ERRCODE_STATEMENT_TOO_COMPLEX is used in few enough places that
> this wouldn't be too much of a loss of specificity. (Or we could
> give stack overflow its very own ERRCODE.)
We could print the error using :LAST_ERROR_MESSAGE after removing a
potential trailing "at character ..." if we're worried about the loss of
specificity.
> On the whole I find #1 the least unpleasant, as well as the most
> likely to forestall future variants of this issue. It won't dodge
> the PPC64 problem, but I'm willing to keep living with that one
> for now.
Another avenue could be to make ParseFuncOrColumn et al use less stack,
and hope that it avoids the problem. It's a bit insane that we use this
much.
We don't have to go there in this case, but I've before wondered about
adding helpers that use an on-stack var for small allocations, and falls
back to palloc otherwise. Something boiling down to:
Oid actual_arg_types_stack[3];
Oid *actual_arg_types;
if (list_length(fargs) <= lengthof(actual_arg_types_stack))
actual_arg_types = actual_arg_types_stack;
else
actual_arg_types = palloc(sizeof(*actual_arg_types) * list_length(fargs))
Greetings,
Andres Freund