Tom Lane wrote:
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?
I'd say:
1. go with the former
2. we definitely should also have an ALTER command to allow disable/enable of
triggers
3. along with the ALTER, document that directly messing with the system
catalogs is highly discouraged
Joe
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
