Re: failed runcheck

Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> [ core dump due to ]
> #0  IsSystemRelationName (relname=0x0) at catalog.c:176
> #1  0x807ed9a in IsSharedSystemRelationName (relname=0x0) at catalog.c:197
> #2  0x80e9272 in RelationInitLockInfo (relation=0x82af018) at lmgr.c:119
> #3  0x81202ef in formrdesc (relationName=0x816ad7e "pg_class", natts=22, 
>     att=0x8173600) at relcache.c:1193
> #4  0x8120c12 in RelationCacheInitialize () at relcache.c:1953

and proposes to fix this by having IsSystemRelationName make an
arbitrary decision about whether a NULL input pointer should be
considered to represent a system relation name or not.  I do not
like that, because AFAICS the decision is completely arbitrary.
IsSystemRelationName shouldn't be called with a NULL pointer
in the first place, and it has every right to cause a coredump
if that happens.

It looks to me like the immediate bug here is that
RelationGetPhysicalRelationName is returning a NULL pointer.  Probably
there are some missing or out-of-order steps in relcache initialization?

I've been offline for a couple days due to DSL line failure :-( so
I haven't seen Vadim's latest checkins.  But I'm betting this is a bug
in the changes to use OIDs as physical relnames.  Do we even need
RelationGetPhysicalRelationName anymore, and if so, what does it mean?

Next question: why is RelationInitLockInfo using
RelationGetPhysicalRelationName to get the input data for
IsSharedSystemRelationName --- shouldn't that be a test on logical
relation name?  Or maybe the entire premise of
IsSharedSystemRelationName is bogus now, and we ought to use some other
way to decide if a relation is cross-database or not?
        regards, tom lane