Re: statement_timeout is not cancelling query
От | Robert Haas |
---|---|
Тема | Re: statement_timeout is not cancelling query |
Дата | |
Msg-id | 603c8f070912151230t2c90fdecp6aa8a45a0c3c69b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: statement_timeout is not cancelling query (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: statement_timeout is not cancelling query
|
Список | pgsql-bugs |
On Tue, Dec 15, 2009 at 1:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Dec 15, 2009 at 1:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Alvaro Herrera <alvherre@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. =A0The > 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. =A0Not 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
В списке pgsql-bugs по дате отправления: