Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id E2336633648; Tue, 20 Apr 2010 11:48:56 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 24234-02-5; Tue, 20 Apr 2010 14:48:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from gw.wicourts.gov (gwmta.wicourts.gov [165.219.244.99]) by mail.postgresql.org (Postfix) with ESMTP id 622D46365C4; Tue, 20 Apr 2010 11:24:48 -0300 (ADT) Received: from Courts-MTA by gw.wicourts.gov with Novell_GroupWise; Tue, 20 Apr 2010 09:24:47 -0500 Message-Id: <4BCD72D60200002500030BBA@gw.wicourts.gov> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Apr 2010 09:24:38 -0500 From: "Kevin Grittner" To: "Robert Haas" , "Tom Lane" Cc: "Josh Berkus" , "Heikki Linnakangas" , "Fujii Masao" , , "PostgreSQL-development" Subject: Re: [HACKERS] Streaming replication document improvements References: <3f0b79eb1003300152g5327eb47w8f9aecae6002b215@mail.gmail.com> <19262.1270142946@sss.pgh.pa.us> <4BB4952D0200002500030333@gw.wicourts.gov> <4BB4DBEF.3010301@agliodbs.com> <26449.1271772517@sss.pgh.pa.us> In-Reply-To: <26449.1271772517@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.096 tagged_above=-10 required=5 tests=AWL=-2.313, BAYES_00=-1.9, FS_REPLICA=3.599, SARE_SPEC_REPLICA=0.72, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201004/70 X-Sequence-Number: 5469 Tom Lane wrote: > Robert Haas writes: >> Fujii Masao wrote: >>> 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. > > +1. I'm not sure about the consequences of converting walsender > to non-superuser across the board, and would prefer not to > experiment with it at this stage of the release cycle. +1 -Kevin