Re: replication_reserved_connections

On Sun, Jul 28, 2013 at 2:50 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-07-28 02:23:47 +0200, Marko Tiikkaja wrote:
>> While you could limit the number of connections for non-replication roles,
>> that's not always possible or desirable.  I would like to introduce a way to
>> reserve connection slots for replication.  However, it's not clear how this
>> would work.  I looked at how superuser_reserved_connections is implented,
>> and with small changes I could see how to implement two ideas:
>>
>> Does anyone see a better way to do this?  I'm not too satisfied with either
>> of these ideas.
>
> Personally I think we should just shouldn't allow normal connections for
> the backend slots added by max_wal_senders. They are internally *added*
> to max_connections, so limiting that seems perfectly fine to me since
> the system provides max_connections connections externally.
>
> Hm... I wonder how that's managed for 9.4's max_worker_processes.

See InitProcGlobal().  There are three lists of PGPROC objects.
PGPROCs for incoming connections are pulled off of
ProcGlobal->freeProcs, the autovacuum and its workers pull from
ProcGlobal->autovacFreeProcs, and background workers pull from
ProcGlobal->bgworkerFreeProcs.  Auxiliary processes have a separate
pool of PGPROCs to pull from, but they use linear search rather than a
list, for reasons described in the comments in that function.

There may be other checks elsewhere that enforce these same limits; not sure.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company