Re: CLOBBER_CACHE_ALWAYS regression instability

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