Re: Patch for reserved connections for replication users

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Gibheer <gibheer(at)zero-knowledge(dot)org>, Marko Tiikkaja <marko(at)joh(dot)to>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch for reserved connections for replication users
Date: 2013-08-08 13:35:29
Message-ID: CA+TgmoY4d_JdVwk5456hda7gfyf1xyONqhY34agmcFsAvyT4iA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 5, 2013 at 2:04 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> Hmm. It seems like this match is making MaxConnections no longer mean
>> the maximum number of connections, but rather the maximum number of
>> non-replication connections. I don't think I support that
>> definitional change, and I'm kinda surprised if this is sufficient to
>> implement it anyway (e.g. see InitProcGlobal()).
>
> I don't think the implementation is correct, but why don't you like the
> definitional change? The set of things you can do from replication
> connections are completely different from a normal connection. So using
> separate "pools" for them seems to make sense.
> That they end up allocating similar internal data seems to be an
> implementation detail to me.

Because replication connections are still "connections". If I tell
the system I want to allow 100 connections to the server, it should
allow 100 connections, not 110 or 95 or any other number.

I'm also not sure the decision about whether something is a WAL sender
is made early enough for the distinction to really make sense. WAL
senders actually start off, from the postmaster's POV, as regular
backends, and then become walsenders "on the fly".

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jon Nelson 2013-08-08 15:28:55 Re: 9.4 regression
Previous Message Robert Haas 2013-08-08 13:33:07 Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])