|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: Why is infinite_recurse test suddenly failing?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2019-05-02 11:02:03 -0400, Tom Lane wrote:
> In the past week, four different buildfarm members have shown
> non-reproducing segfaults in the "select infinite_recurse()"
> test case, rather than the expected detection of stack overrun
> before we get to the point of a segfault.
I was just staring at bonito's failure in confusion.
> They're all on HEAD, and they all look like
> 2019-05-01 23:11:00.145 UTC [13933:65] LOG: server process (PID 17161) was terminated by signal 11: Segmentation fault
> 2019-05-01 23:11:00.145 UTC [13933:66] DETAIL: Failed process was running: select infinite_recurse();
> I scraped the buildfarm database and verified that there are no similar
> failures for at least three months back; nor, offhand, can I remember ever
> having seen this test fail in many years. So it seems we broke something
> recently. No idea what though.
I can't recall any recent changes to relevant area of code.
> (Another possibility, seeing that these are all members of Mark's PPC64
> flotilla, is that there's some common misconfiguration --- but it's hard
> to credit that such a problem would only affect HEAD not the back
Hm, I just noticed:
'HEAD' => [
'force_parallel_mode = regress'
on all those animals. So it's not necessarily the case that HEAD and
backbranch runs are behaving all that identical. Note that isn't a
recent config change, so it's not an explanation as to why they started
to fail only recently.
|Next Message||Tom Lane||2019-05-02 15:41:28||Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6|
|Previous Message||Andres Freund||2019-05-02 15:32:43||Re: New vacuum option to do only freezing|