Re: max_connections documentation - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: max_connections documentation
Date
Msg-id 54B43F5F.9060600@BlueTreble.com
Whole thread Raw
In response to Re: max_connections documentation  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 1/10/15 12:06 AM, Amit Kapila wrote:
> On Sat, Jan 10, 2015 at 6:20 AM, Jim Nasby <Jim.Nasby@bluetreble.com <mailto:Jim.Nasby@bluetreble.com>> wrote:
>  >
>  > I'm surprised to see that the docs make no mention of how max_connections, max_worker_processes and
autovacuum_max_workers(don't) relate. I couldn't remember and had to actually look at the code. I'd like to clarify
thisin the max_connecitons section of the documents by doing s/connections/user connections/ and including the formula
forMaxBackends (MaxBackends = MaxConnections + autovacuum_max_workers + 1 + max_worker_processes). I'll also mention
thatany postgres_fdw connections are considered user connections.
 
>  >
>
> I think it makes sense to add such a clarification in docs, however
> not sure if specifying along with max_connections parameter is
> good idea as the formula is somewhat internal and is not directly
> related to max_connections.

It's not all that internal; it directly controls how many entries you could end up with in pg_stat_activity. Certainly
monitoringsoftware needs to be aware of how this stuff works, and I think many DBAs would want to know as well. Maybe
wedon't need the formula itself, but we need to explain what backends do not count towards max_connections (and ideally
howto identify them).
 

Maybe the best thing would be to add an "internal" field to pg_stat_activity to indicate what backends were internal
andnot user-related...
 

>  How about specifying in below page:
>
> http://www.postgresql.org/docs/devel/static/connect-estab.html

I think someone that's concerned about connection limits is much more likely to look at the config section of the docs
thanthat section, so we'd need to cross-reference them. Which would probably be good to do anyway...
 
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: Sequence Access Method WIP
Next
From: Pavel Stehule
Date:
Subject: Re: To do for psql to show installable extensions