Re: multi-tenant vs. multi-cluster - Mailing list pgsql-general

From Scott Marlowe
Subject Re: multi-tenant vs. multi-cluster
Date
Msg-id AANLkTin8rQaSs+Q8B+=CdK5or_H1yo7Afx4P7gS-95X6@mail.gmail.com
Whole thread Raw
In response to Re: multi-tenant vs. multi-cluster  (Ben Chobot <bench@silentmedia.com>)
List pgsql-general
On Fri, Mar 18, 2011 at 1:44 PM, Ben Chobot <bench@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.

pgsql-general by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: How do I do this in plpgsql ?
Next
From: Adrian Klaver
Date:
Subject: Re: pgagent installation -- ccmake - getting selected wxWidgets configuration (version: 2.6, debug: no, static