On Fri, Mar 18, 2011 at 1:44 PM, Ben Chobot 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
On Fri, Mar 18, 2011 at 2:44 PM, Ben Chobot 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 instance, y
> -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, a
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
> numb
> -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.
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
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 mem
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 af
