Re: ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,9) not found
От | Kristis Makris |
---|---|
Тема | Re: ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,9) not found |
Дата | |
Msg-id | 200107111604.f6BG4ka39360@postgresql.org обсуждение исходный текст |
Ответ на | Re: ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,9) not found (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
Hi Tom, thanks for your feedback on this. On 11 Jul 2001 11:21:35 -0400, Tom Lane wrote: > pgsql-bugs@postgresql.org writes: > > ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,9) not found > > Hmm, are you trying to create triggers on pg_shadow? It's hard to see > how that message could come from an "UPDATE pg_shadow" otherwise. I'm not trying to explicitly create triggers on pg_shadow. None of the triggers/tables/sequences/functions I've created so far try to reference the pg_shadow in any way, so I don't *believe* (but I could be wrong) that I've even implicitly created a trigger on pg_shadow; > Triggers on system catalogs don't work very well, because they won't > be invoked as a side effect of system-initiated operations. In this > situation, it appears that the trigger code sees that the pg_shadow row > was inserted in the current transaction, so it tries to look up the row > in the list of pending trigger events --- and doesn't find an entry, > because CREATE USER didn't invoke the trigger code. Before I came across this error, the approach I was following was: -Call the WATSUSer_iou() plpgsql function that contained "CREATE USER" statements to create the new user -Call a plpgsql function after that, that contained "UPDATE pg_shadow" statements to update the "valuntil" field from the pg_shadow table. This approach was working fine. I get the feeling that this approach had the effect of each function call being considered a separate transaction, thus there were no errors when the "UPDATE pg_shadow" statement was called (the "CREATE USER" transaction was commited by that time) > In a perfect world we'd support user-defined triggers on the system > catalogs, but given the potential circularity problems, I doubt it's > going to happen real soon. I'd suggest finding another approach. Sounds reasonable. I can stick to the old approach. In case you guys ever need to debug/ look into this I have a schema and a sequence of commands executed that I'll keep around. Thanks for your help. -Kristis
В списке pgsql-bugs по дате отправления: