Re: Recent SIGSEGV failures in buildfarm HEAD

Tom Lane wrote:
> Seneca Cunningham <tentra(at)gmail(dot)com> writes:
>> I don't have a core, but here's the CrashReporter output for both
>> of jackal's failed runs:
>
> Wow, some actual data, rather than just noodling about how to get it ...
> thanks!
>
>> ...
>> 11 postgres 0x0022b2e3 RelationIdGetRelation + 110 (relcache.c:1496)
>> 12 postgres 0x00020868 relation_open + 84 (heapam.c:697)
>> 13 postgres 0x0002aab9 index_open + 32 (indexam.c:140)
>> 14 postgres 0x0002a9d4 systable_beginscan + 289 (genam.c:184)
>> 15 postgres 0x002279e4 RelationInitIndexAccessInfo + 1645 (relcache.c:1200)
>> 16 postgres 0x0022926a RelationBuildDesc + 3527 (relcache.c:866)
>> 17 postgres 0x0022b2e3 RelationIdGetRelation + 110 (relcache.c:1496)
>> 18 postgres 0x00020868 relation_open + 84 (heapam.c:697)
>> 19 postgres 0x0002aab9 index_open + 32 (indexam.c:140)
>> 20 postgres 0x0002a9d4 systable_beginscan + 289 (genam.c:184)
>> 21 postgres 0x002279e4 RelationInitIndexAccessInfo + 1645 (relcache.c:1200)
>> 22 postgres 0x0022926a RelationBuildDesc + 3527 (relcache.c:866)
>> 23 postgres 0x0022b2e3 RelationIdGetRelation + 110 (relcache.c:1496)
>> ...
>
> What you seem to have here is infinite recursion during relcache
> initialization. That's surely not hard to believe, considering I just
> whacked that code around, and indeed changed some of the tests that are
> intended to prevent such recursion. But what I don't understand is why
> it'd be platform-specific, much less not perfectly repeatable on the
> platforms where it does manifest. Anyone have a clue?

fwiw - I can trigger that issue now pretty reliably on a fast Opteron
box (running Debian Sarge/AMD64) with make regress in a loop - I seem to
be able to trigger it in about 20-25% of the runs.
the resulting core however looks totally stack corrupted and not really
usable :-(

Stefan