On Tue, Apr 20, 2010 at 9:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> Yeah, I agree with you, but the difference is only how to achieve.
> ISTM that there are three choices:
>
> 1. Heikki's proposal
>> ReservedBackends = superuser_reserved_connections + max_wal_senders
>> MaxBackends = max_connections + autovacuum_max_workers + max_wal_senders + 1
This seemed sensible to me when Heikki first described it, but now it
seems overly complex.
> 2. My proposal
> Remove superuser privilege from replication connection
I'm not sure this really fixes the problem. If we add a separate
replication privilege, then presumably superusers will automatically
have that privilege, in accord with our usual policy on such things.
So potentially someone could still set up replication using a
superuser account and then they could still get bitten by this
problem.
> 3. Your proposal
> Treat superuser replication connection like non-superuser one
Well, only for this one very specific purpose. I would adjust the
docs like this:
Determines the number of connection "slots" that are reserved for
connections by PostgreSQL superusers. At most max_connections
connections can ever be active simultaneously. Whenever the number of
active concurrent connections is at least max_connections minus
superuser_reserved_connections, new connections will be accepted only
for superusers, and no new replication connections will be accepted.
I think that's pretty simple and clear. If we want to burn an extra
sentence explaining what this is all about, we could add:
(If replication connections were permitted to use the reserved
connection slots, an installation with max_wal_senders set to a value
greater than or equal to the value set for
superuser_reserved_connections might find that no reserved connections
remained for interactive access to the database.)
> Since 3. is confusing for me, I like 1. or 2.
What do others think?
...Robert
