From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Joao Junior <jcoj2006(at)gmail(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: max_connections |
Date: | 2019-10-22 12:39:19 |
Message-ID: | CAFj8pRAiVDnJpcxxSss1uy_LEDGy+pS9b2dx6dkqV+nF_=uAXw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi
út 22. 10. 2019 v 14:28 odesílatel Joao Junior <jcoj2006(at)gmail(dot)com> napsal:
> Hi,
> I am not sure if here is the best place to post this.
> I would like to know why max_connections parameter can't be changed
> without a restart. I know that it is a postmaster's context parameter.
> Which PostgreSQL's subsystems, structures and OS kernel parameters
> should be affected to support this change??
>
The max_connections is used more time inside PostgreSQL source code -
typically for dimensions arrays where one field is per session.
You can search in source code the variable "MaxConnections". It's used for
informations about sessions (processes), about transactions, locks, ..
Unfortunately, lot of these arrays are allocated in shared memory. For
shared memory has Postgres special coding standards - almost all memory is
allocated in startup time, and newer released. It is very simple to manage
memory with these rules. It is fast, and there are not any risk of memory
leaks. But related limits requires restart. Usually it is not a problem. So
necessity of restart after change of max_connection is related to simple
but very robust share memory management.
Regards
Pavel
> Thanks!
>
From | Date | Subject | |
---|---|---|---|
Next Message | Grégoire de Turckheim | 2019-10-28 13:42:03 | Notifications within triggers seem to compromise performance |
Previous Message | Joao Junior | 2019-10-22 12:28:31 | max_connections |