Re: pgsql 7.2.3 crash - Mailing list pgsql-hackers

Yeah I think that could have happened since I was running it several times and had
cancelled it (ctrl-c) it a couple of those times.  Could be the backend of one 
cancelled run hadn't finished what it was doing and if that was renabling
triggers it could have walked on it.

Thanks.

L.
On Sat, 12 Oct 2002, Tom Lane wrote:

> Laurette Cisneros <laurette@nextbus.com> writes:
> > I see triggers referenced here and it should be
> > noted that for one of the tables the triggers were first disabled (update
> > pg_class) and re-enabled after the inserts are done (or it takes
> > forever).
> >> 
> >> Did that happen while this backend was running?
> 
> > Yes.  I had run this perl program about 4-5 times in a row (which includes
> > the sequence, disable triggers, insert rows, enable triggers) and then it
> > crashed on one of the runs.
> 
> Hm.  The stack trace shows that this backend crashed while executing the
> command
>     insert into jobsequences select * from rev_000_jobsequences
> Is it possible that you disabled and re-enabled triggers on jobsequences
> *while this command was running* ?
> 
> The gdb info makes it look like the triggers code is using a stale
> trigger description structure.  The pointer that's being used is cached
> in the ResultRelInfo struct (ri_TrigDesc) during query startup.  If
> some external operation changed the trigger state while the query is
> running, trouble would ensue.
> 
> This looks like something we ought to fix in any case, but I'm unsure
> whether it explains your crash.  Do you think that that's what could
> have happened?
> 
> 
> 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?
> 
>             regards, tom lane
> 

-- 
Laurette Cisneros
The Database Group
(510) 420-3137
NextBus Information Systems, Inc.
www.nextbus.com
------------------------------
It's 10 o'clock...
Do you know where your bus is?