Skip site navigation (1) Skip section navigation (2)

Re: Limiting number of connections to PostgreSQL per IP (not per DB/user)?

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: (view raw, whole thread or download thread mbox)
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!


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

conn_a = host= port=5432 user=user_a password='a' dbname=db_a
conn_b = host= port=5432 user=user_a password='a' dbname=db_a

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

Each customer will get different credential and his own db name (in


In response to

pgsql-general by date

Next:From: panamDate: 2011-11-30 01:32:18
Subject: Re: Extending the volume size of the data directory volume
Previous:From: Tomas VondraDate: 2011-11-29 23:15:39
Subject: Re: Query Optimizer makes a poor choice

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group