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