Hi,
On 2020-04-05 19:54:19 -0400, Alvaro Herrera wrote:
> Isn't it the case that you can create an inner block with a constant
> whose size is determined by a containing block's variable? I mean as in
> the attached, which refuses to compile because of our -Werror=vla -- but
> if I remove it, it
On 2020-Apr-05, Tom Lane wrote:
> What I wish we had was alloca(), so you don't need a FUNC_MAX_ARGS-sized
> array to parse a two-argument function call. Too bad C99 didn't add
> that. (But some sniffing around suggests that an awful lot of systems
> have it anyway ... even MSVC. Hmmm.)
Isn't
On 2020-04-05 15:38:29 -0400, Tom Lane wrote:
> Andres Freund writes:
> > 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.
>
> Oh, actually it seems that :LAST_ERROR_MESSAGE is already
Andres Freund writes:
> On 2020-04-05 15:04:30 -0400, Tom Lane wrote:
>> That would only reduce the chance of getting a stack overflow there,
>> and not by that much, especially not for a CLOBBER_CACHE_ALWAYS animal
>> which is going to be doing catalog accesses inside there too.
> It'd certainly
Andres Freund writes:
> On 2020-04-05 14:33:19 -0400, Tom Lane wrote:
>> 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.
Hi,
On 2020-04-05 15:04:30 -0400, Tom Lane wrote:
> Andres Freund writes:
> > 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.
>
> That would only reduce the chance of getting a stack ove
Andres Freund writes:
> 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.
That would only reduce the chance of getting a stack overflow there,
and not by that much, especially not for a CLOBBER
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,
Over in the thread at [1] we were wondering how come buildfarm member
hyrax has suddenly started to fail like this:
diff -U3
/home/buildfarm/buildroot/HEAD/pgsql.build/src/test/regress/expected/errors.out
/home/buildfarm/buildroot/HEAD/pgsql.build/src/test/regress/results/errors.out
---
/home/b
