On Tue, Dec 15, 2009 at 1:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Dec 15, 2009 at 1:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Alvaro Herrera <alvhe...@commandprompt.com> writes: >>>> If we're to do anything about this, it is spilling the trigger queue so >>>> it doesn't eat an unbounded amount of memory. >>> >>> Of course, the reason nothing much has been done about that is that >>> by the time your trigger queue is long enough to cause such an issue, >>> you're screwed anyway --- actually executing all those triggers would >>> take longer than you'll want to wait. > >> What is the best way to go about doing that, anyway? > > Well, we added conditional triggers which provides a partial fix. The > only other idea I've heard that sounds like it'd really help is having > some sort of lossy storage for foreign-key triggers, where we'd fall > back to per-block or whole-table rechecking of the constraint instead of > trying to track the exact rows that were modified. Not sure how you > apply that to non-FK triggers though.
Err, sorry, I quoted the wrong part. I meant, how would you rlimit the server memory usage? ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
