Re: multi-tenant vs. multi-cluster

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: multi-tenant vs. multi-cluster
Дата
Msg-id AANLkTin8rQaSs+Q8B+=CdK5or_H1yo7Afx4P7gS-95X6@mail.gmail.com
обсуждение исходный текст
Ответ на Re: multi-tenant vs. multi-cluster  (Ben Chobot <bench@silentmedia.com>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: How do I do this in plpgsql ?
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: pgagent installation -- ccmake - getting selected wxWidgets configuration (version: 2.6, debug: no, static