Re: max_wal_senders must die

Magnus Hagander wrote:
> On Tue, Oct 19, 2010 at 13:14, Stefan Kaltenbrunner
> <stefan@kaltenbrunner.cc> wrote:
>> Josh Berkus wrote:
>>> Hackers,
>>>
>>> What purpose is served, exactly, by max_wal_senders?
>>>
>>> In order for a standby to connect, it must have a superuser login, and
>>> replication connections must be enabled in pg_hba.conf.  How is having one
>>> more setting in one more file you have to enable on the master benefitting
>>> anyone?
>>>
>>> Under what bizarre set of circumstances would anyone have runaway
>>> connections from replicas to the master?
>>>
>>> Proposed that we simply remove this setting in 9.1.  The real maximum wal
>>> senders should be whatever max_connections is.
>> I disagree - limiting the maximum number of replication connections is
>> important for my usecases.
>> Replication connections are significantly more heavilyweight than a normal
>> connection and right now I for example simply use this setting to prevent
>> stupid mistakes (especially in virtualized^cloudstyle environments).
>>
>> What we really should look into is using a less privileged role - or
>> dedicated replication role - and use the existing per role connection limit
>> feature. That  feature is unlimited by default, people can change it like
>> for every role and we can git rid of that guc.
> 
> +1 for being able to control it that wya - that should keep it simple
> for the newbie usecase, while retaining the ability for fine-grained
> control for those who need it.
> 
> I think it's already on the TODO for 9.1 to use a separate role for it...

I Think we had some plans to do that - I wonder how hard it would be to 
just do the dedicated role thing for now (maybe with the only constraint 
that it can only be used on a replication connection) and looking into 
making it (technically) less privileged later?

> 
> If we want something fixed *now*, should we perhaps just bump the
> *default* value for max_wal_senders to 5 or something?

or accept -1 for "unlimited" and use by default, that would fix part of 
the complaint from josh but you would still have to restart the master 
to implement a limit...



Stefan