On Tue, Apr 20, 2010 at 9:47 AM, Fujii Masao <masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
