Re: pgsql 7.2.3 crash

Gavin Sherry wrote:
> On Sat, 12 Oct 2002, Joe Conway wrote:
> 
> > 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
> 
> I agree.
> 
> > 2. we definitely should also have an ALTER command to allow disable/enable of
> >     triggers
> 
> I thought this was worked on for 7.3? I remember speaking to someone
> (?) at OSCON because I had been working on 'ENABLE TRIGGER <trigname>' and
> is compliment on the plane. Much of the work seemed to have been in CVS
> already.

It is in TODO:
* Allow triggers to be disabled [trigger]

From the TODO.detail archives, it seems it got stuck on an
implementation issue:
http://candle.pha.pa.us/mhonarc/todo.detail/trigger/msg00001.html

The patch didn't prevent deferred contraint triggers from being fired.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073