Re: AW: Coping with huge deferred-trigger lists - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: AW: Coping with huge deferred-trigger lists
Date
Msg-id Pine.BSF.4.21.0105101057210.92606-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Re: AW: Coping with huge deferred-trigger lists  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> If we do that then we still have a problem with overrunning memory
> after a sufficiently large number of tuples.  However, that'd improve
> the constant factor by at least an order of magnitude, so it might be
> worth doing as an intermediate step.  Still have to figure out whether
> the triggered-data-change business is significant or not.

I think that was part of the misunderstanding of the spec.  I think the
spec means it to be within one statement (and its associated immediate
actions) rather than rest of transaction.  I think it's mostly to
prevent loop cases A row 1 modifies B row 1 modifies A row 1 modifies ... 
However, I only looked at it briefly a while back.



pgsql-hackers by date:

Previous
From: bpalmer
Date:
Subject: Re: Regression tests for OBSD scrammed..
Next
From: Mark Hollomon
Date:
Subject: Re: Re: PL/Python build