Patrick Welche <prlw1@newn.cam.ac.uk> writes:
>> Could you try setting a breakpoint at elog() to capture the stack trace
>> leading up to the error?
> #0 elog (lev=15, fmt=0x821133b "statement: %s") at elog.c:114
> #1 0x81812db in elog (lev=20, fmt=0x8196b02 "Relation %u does not exist")
> at elog.c:438
> #2 0x80791a2 in relation_open (relationId=0, lockmode=2) at heapam.c:474
> #3 0x8079329 in heap_open (relationId=0, lockmode=2) at heapam.c:602
> #4 0x816d94b in RI_FKey_check (fcinfo=0xbfbfc884) at ri_triggers.c:212
> #5 0x816dee1 in RI_FKey_check_ins (fcinfo=0xbfbfc884) at ri_triggers.c:506
Hm. Apparently tgconstrrelid is 0 in the pg_trigger row for your ON
INSERT trigger --- can you confirm that by looking in pg_trigger?
Next question is how it got that way. Did you create this table from a
dump, and if so do you still have the dump file? I'm wondering exactly
what SQL command was used to create the trigger ...
> I was inserting meter_id=411, stats_id=currval('stats_id_seq')
> meter.id=411 exists. Hard to tell about the other one.. Still don't see
> why this ever worked..
I'm confused about that too. The trigger failure is definitely
happening after we insert the row, so currval() must have gotten done
before reaching this point. So *something* is executing a nextval()
before we get to the point of evaluating the currval(). You got any
defaults on the table that might do it?
regards, tom lane