Laurette Cisneros <[EMAIL PROTECTED]> writes:
> I see triggers referenced here and it should be
> noted that for one of the tables the triggers were first disabled (update
> pg_class) and re-enabled after the inserts are done (or it takes
> forever).
>>
>> Did that happen while this backend was running?
> Yes. I had run this perl program about 4-5 times in a row (which includes
> the sequence, disable triggers, insert rows, enable triggers) and then it
> crashed on one of the runs.
Hm. The stack trace shows that this backend crashed while executing the
command
insert into jobsequences select * from rev_000_jobsequences
Is it possible that you disabled and re-enabled triggers on jobsequences
*while this command was running* ?
The gdb info makes it look like the triggers code is using a stale
trigger description structure. The pointer that's being used is cached
in the ResultRelInfo struct (ri_TrigDesc) during query startup. If
some external operation changed the trigger state while the query is
running, trouble would ensue.
This looks like something we ought to fix in any case, but I'm unsure
whether it explains your crash. Do you think that that's what could
have happened?
Hackers: we might reasonably fix this by doing a deep copy of the
relcache's trigger info during initResultRelInfo(); or we could fix it
by getting rid of ri_TrigDesc and re-fetching from the relcache every
time. The former would imply that trigger state would remain unchanged
throughout a query, the latter would try to track currently-committed
trigger behavior. Either way has got pitfalls I think.
The fact that there's a problem at all is because people are using
direct poking of the system catalogs instead of some kind of ALTER TABLE
command to disable/enable triggers; an ALTER command would presumably
gain exclusive lock on the table and thereby delay until active queries
finish. But that technique is out there (even in pg_dump files :-() and
so we'd best try to make the system proof against it.
Any thoughts on which way to go?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
