Re: Visibility Groups

Поиск
Список
Период
Сортировка
Искать
От
Decibel!
Тема
Re: Visibility Groups
Дата
Msg-id
39C3616B-B407-4090-9E29-BC68CEF638D2@decibel.org
Ответ на
Re: Visibility Groups (Robert Haas)
Список
Дерево обсуждения
Visibility Groups Simon Riggs <simon@2ndquadrant.com>
Re: Visibility Groups Alvaro Herrera <alvherre@commandprompt.com>
Re: Visibility Groups Simon Riggs <simon@2ndquadrant.com>
Re: Visibility Groups Tom Lane <tgl@sss.pgh.pa.us>
Re: Visibility Groups Simon Riggs <simon@2ndquadrant.com>
Re: Visibility Groups "Robert Haas" <robertmhaas@gmail.com>
Re: Visibility Groups Decibel! <decibel@decibel.org>
Re: Visibility Groups Gregory Stark <stark@enterprisedb.com>
Re: Visibility Groups Alvaro Herrera <alvherre@commandprompt.com>
Re: Visibility Groups Gregory Stark <stark@enterprisedb.com>
Re: Visibility Groups Gregory Stark <stark@enterprisedb.com>
Re: Visibility Groups "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: Visibility Groups Gregory Stark <stark@enterprisedb.com>
Re: Visibility Groups Simon Riggs <simon@2ndquadrant.com>
Re: Visibility Groups daveg <daveg@sonic.net>
Re: Visibility Groups "Jochem van Dieten" <jochemd@gmail.com>
Re: Visibility Groups Simon Riggs <simon@2ndquadrant.com>
Re: Visibility Groups Richard Huxton <dev@archonet.com>
Re: Visibility Groups Simon Riggs <simon@2ndquadrant.com>
Re: Visibility Groups Richard Huxton <dev@archonet.com>
On Aug 7, 2008, at 9:49 AM, Robert Haas wrote:
> This proposal sounds like it would target batch jobs, because those
> are the kinds of jobs that where you can predict in advance what
> tables will be needed.  I don't know whether my personal set of
> problems with MVCC syncs up with anyone else's, but this is rarely how
> I get bitten.  Usually, what happens is that a user session (psql or
> web server connection) gets left in a transaction for days or weeks.
> Now the batch jobs (which are doing lots of updates) start creating
> tons of bloat, but it's not their snapshot that is causing the
> problem.


We have some cron'd scripts that check for long-running queries, idle  
in transaction and just plain idle. The scripts will kill sessions  
when the sit in different states for too long. It would be nice if  
the database could handle this (no, statement_timeout won't work,  
because the user can just change it to whatever they want), but I  
don't know how many other people have this need. I guess I could at  
least put the scripts up on pgFoundry...
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828


В списке pgsql-hackers по дате отправления
От: Decibel!
Дата:
Сообщение: Re: IN vs EXISTS equivalence
От: Decibel!
Дата:
FAQ