Re: backup manifests and contemporaneous buildfarm failures - Mailing list pgsql-hackers

From Tom Lane
Subject Re: backup manifests and contemporaneous buildfarm failures
Date
Msg-id 11691.1586012252@sss.pgh.pa.us
Whole thread Raw
In response to Re: backup manifests and contemporaneous buildfarm failures  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: backup manifests and contemporaneous buildfarm failures  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> hyrax's last run was before any of this happened, so it seems to have
> an unrelated problem. The last two runs, three and six days ago, both
> failed like this:

> -ERROR:  stack depth limit exceeded
> +ERROR:  stack depth limit exceeded at character 8

> Not sure what that's about.

What it looks like is that hyrax is managing to detect stack overflow
at a point where an errcontext callback is active that adds an error
cursor to the failure.

It's not so surprising that we could get a different result that way
from a CLOBBER_CACHE_ALWAYS animal like hyrax, since CCA-forced
cache reloads would cause extra stack expenditure at a lot of places.
And it could vary depending on totally random details, like the number
of local variables in seemingly unrelated code.  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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: backup manifests
Next
From: Tom Lane
Date:
Subject: Re: adding partitioned tables to publications