We're considering using postgres as a way to host database services for many,
many independent applications. One obvious way to do this is with schemas,
roles, and proper permissions, but that still leaves open the possibility for
some poorly written application to leave open transactions and
On 18/03/2011 19:17, Ben Chobot wrote:
if we're talking an extra 50MB of memory per cluster, that will start to add up.
Consider this: each such cluster will have:
a) its own database files on the drives (WAL, data - increasing IO)
b) its own postgresql processes (many of them) running in
On Mar 18, 2011, at 11:47 AM, Ivan Voras wrote:
On 18/03/2011 19:17, Ben Chobot wrote:
if we're talking an extra 50MB of memory per cluster, that will start to add
up.
Consider this: each such cluster will have:
a) its own database files on the drives (WAL, data - increasing IO)
Oh,
-Original Message-
From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
ow...@postgresql.org] On Behalf Of Ben Chobot
Sent: Friday, March 18, 2011 3:10 PM
To: Ivan Voras
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] multi-tenant vs. multi-cluster
On Mar 18
On Mar 18, 2011, at 12:34 PM, Nicholson, Brad (Toronto, ON, CA) wrote:
b) its own postgresql processes (many of them) running in memory
I believe this is entirely a function of client connections.
With a single instance, you can use connection pooling to reduce the overall
number of
-Original Message-
From: Ben Chobot [mailto:be...@silentmedia.com]
Sent: Friday, March 18, 2011 3:45 PM
To: Nicholson, Brad (Toronto, ON, CA)
Cc: pgsql-general General
Subject: Re: [GENERAL] multi-tenant vs. multi-cluster
On Mar 18, 2011, at 12:34 PM, Nicholson, Brad (Toronto
On Fri, Mar 18, 2011 at 2:44 PM, Ben Chobot be...@silentmedia.com wrote:
On Mar 18, 2011, at 12:34 PM, Nicholson, Brad (Toronto, ON, CA) wrote:
b) its own postgresql processes (many of them) running in memory
I believe this is entirely a function of client connections.
With a single
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
