Re: pgsql 7.2.3 crash - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: pgsql 7.2.3 crash
Date
Msg-id Pine.LNX.4.21.0210131550220.4797-100000@linuxworld.com.au
Whole thread Raw
In response to Re: pgsql 7.2.3 crash  (Joe Conway <mail@joeconway.com>)
Responses Re: pgsql 7.2.3 crash
Disabling triggers (was Re: pgsql 7.2.3 crash)
List pgsql-hackers
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.

Gavin



pgsql-hackers by date:

Previous
From: Barry Lind
Date:
Subject: Re: Difference between 7.2 and 7.3, possible bug?
Next
From: Mike Mascari
Date:
Subject: Re: Transactions through dblink_exec()