Brent Verner <brent@rcfile.org> writes:
> It is probably noteworthy that I am directly modifying the tgargs
> in the pg_trigger table, via simple_heap_update(). This modfication
> is made at the end of renameatt() in rename.
Seems reasonable.
Now that I think about it, the problem is almost certainly that the
relcache+sinval mechanism isn't recognizing this update as requiring
relcache-entry rebuild. If you update a pg_class row, it definitely
does recognize that event as forcing relcache rebuild, and I had thought
that updating a pg_attribute row associated with a relcache entry would
cause one too. But maybe not. We should either extend the sinval code
to make that happen, or tweak renameatt to force a relcache flush
explicitly.
Alternatively, maybe you're expecting too much? The relcache rebuild
doesn't (and isn't supposed to) happen until the next transaction commit
or CommandCounterIncrement. If you've structured the code in a way that
needs the relcache change to happen sooner, then I think we need to find
a way to avoid expecting that to happen.
> Also, is directly updating the pg_trigger table advisable?
simple_heap_update seems pretty direct to me :-) ... what did you have
in mind?
regards, tom lane