Re: max_connections

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!
>

In response to

Browse pgsql-performance by date

  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