Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Apr 4, 2020 at 10:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What is odd is that
>> (AFAIR) we've never seen this before. Maybe somebody recently added
>> an error cursor callback in a place that didn't have it before, and
>> is involved in SQL-function processing? None of the commits leading
>> up to the earlier failure look promising for that, though.
> The relevant range of commits (e8b1774fc2 to a7b9d24e4e) includes an
> ereport change (bda6dedbea) and a couple of "simple expression"
> changes (8f59f6b9c0, fbc7a71608) but I don't know exactly why they
> would have caused this.
When I first noticed hyrax's failure, some days ago, I immediately
thought of the "simple expression" patch. But that should not have
affected SQL-function processing in any way: the bulk of the changes
were in plpgsql, and even the changes in plancache could not be
relevant, because functions.c does not use the plancache.
As for ereport, you'd think that that would only matter once you were
already doing an ereport. The point at which the stack overflow
check triggers should be in normal code, not error recovery.
> It seems at least possible, though, that
> changing the return type of functions involved in error reporting
> would slightly change the amount of stack space used;
Right, but if it's down to that sort of phase-of-the-moon codegen
difference, you'd think this failure would have been coming and
going for years. I still suppose that some fairly recent change
must be contributing to this, but haven't had time to investigate.
> Other than experimenting on
> that machine, I'm not sure how we could really determine the relevant
> factors here.
We don't have a lot of CCA buildfarm machines, so I'm suspecting that
it's probably not that hard to repro if you build with CCA.
regards, tom lane