On Fri, Mar 18, 2011 at 1:44 PM, Ben Chobot <be...@silentmedia.com> wrote:
> OK, so are there any good ways to keep a bad/clueless user from gumming up a > whole cluster? Something like statement_timeout, but for transactions, seems > like it would be idle. Newer versions of postgresql aren't quite as susceptible to problems of open transactions in one DB affecting another in the same cluster / instance. I.e. if dbA has an open transaction, that will no longer prevent dbB from being properly vacuumed etc. I'd suggest using check_postgresql.pl to keep track of things like open transactions, vacuum wraparound etc. Note that it might be worthwhile to have two or more but not dozens of individual clusters. Let's say you've got a critical app, and a bunch of not so critical apps. You can make a cluster for the more critical app(s) so it's / they're isolated from the other apps if things go wrong. A rogue query using all the memory or IO in the machine up can still be a bit of a problem, of course, but it will be limited if it happens in another cluster. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
