From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Limiting number of connections to PostgreSQL per IP (not per DB/user)? |
Date: | 2011-11-29 23:37:20 |
Message-ID: | 4ED56CB0.4000509@fuzzy.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 29.11.2011 14:49, Heiko Wundram wrote:
> Hello!
>
> Sorry for that subscribe post I've just sent, that was bad reading on my
> part (for the subscribe info on the homepage).
>
> Anyway, the title says it all: is there any possibility to limit the
> number of connections that a client can have concurrently with a
> PostgreSQL-Server with "on-board" means (where I can't influence which
> user/database the clients use, rather, the clients mostly all use the
> same user/database, and I want to make sure that a single client which
> runs amok doesn't kill connectivity for other clients)? I could surely
> implement this with a proxy sitting in front of the server, but I'd
> rather implement this with PostgreSQL directly.
>
> I'm using (and need to stick with) PostgreSQL 8.3 because of the
> frontend software in question.
>
> Thanks for any hints!
Hi,
maybe you could use a pgbouncer - it won't allow you to limit them by
source IP, but maybe you can group them by company or something.
For example like this
[databases]
conn_a = host=127.0.0.1 port=5432 user=user_a password='a' dbname=db_a
pool_size=20
conn_b = host=127.0.0.1 port=5432 user=user_a password='a' dbname=db_a
pool_size=10
The users will then connect just like today, but they'll connect to the
pgbouncer using dbnames conn_a and conn_b. Those using conn_a will be
able to use 20 connection, those using conn_b will be able to use 10
connections.
Each customer will get different credential and his own db name (in
pgbouncer).
Tomas
From | Date | Subject | |
---|---|---|---|
Next Message | panam | 2011-11-30 01:32:18 | Re: Extending the volume size of the data directory volume |
Previous Message | Tomas Vondra | 2011-11-29 23:15:39 | Re: Query Optimizer makes a poor choice |