Received: from maia.hub.org (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 6889A63499B;
	Thu,  1 Apr 2010 14:19:22 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia,
	port 10024)
	with ESMTP id 65830-03-6; Thu,  1 Apr 2010 17:19:11 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com
	[209.85.220.222])
	by mail.postgresql.org (Postfix) with ESMTP id 6AB59634374;
	Thu,  1 Apr 2010 14:18:47 -0300 (ADT)
Received: by fxm22 with SMTP id 22so1157523fxm.34
	for <multiple recipients>; Thu, 01 Apr 2010 10:18:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:mime-version:received:in-reply-to:references
	:date:received:message-id:subject:from:to:cc:content-type;
	bh=sZrQxqh3K+YBZwM5eilfIxAiMt1t0QBKFb9BxAI20vw=;
	b=KHJKe7UQPa27lFbH41W8c4pmajhSWwATRHN/9Z6qABoiqUr3mqS8glvk5prbh/SKuZ
	tVIkweJUEi9a08OqjGKCqNIx0E+J8uPoRmum04wL7pPnaAVgMwii8cTMFE1cos4hNifz
	YhiwMBEyBZBJg0d7cvjJa8Ffiu1cE2eWamKvU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	b=D1dEHwKVjk4nWD4zjS5S/6WR6XlEbO0ri5FN6M2QA7KEPSE6vTUH04JQ3n74TYsgD7
	ZjpjZNbI46VV05jaqbmIPuxSAnyyqn1/aTd1uPFSq18qL/jZa1826RqMoHbEMhSJ4FVW
	flj5U2RNu29U4My3k6G9oCEctKVckriaT13pY=
MIME-Version: 1.0
Received: by 10.239.161.83 with HTTP; Thu, 1 Apr 2010 10:18:45 -0700 (PDT)
In-Reply-To: <4BB49B0C.1050901@enterprisedb.com>
References: <3f0b79eb1003300152g5327eb47w8f9aecae6002b215@mail.gmail.com>
	<4BB3B2ED.5080606@enterprisedb.com>
	<u2w3f0b79eb1003311850m50193801tb49b04966f5544d0@mail.gmail.com>
	<t2m603c8f071003311852x3dd15512uc92e0865ba729548@mail.gmail.com>
	<g2z3f0b79eb1003311858y7f781c7u99e09e32c96aa79b@mail.gmail.com>
	<x2t603c8f071003311900v524ab37x44f9e52a2a69dc33@mail.gmail.com>
	<o2u3f0b79eb1003311914i6c9d896bic3d1b13152c6b0d8@mail.gmail.com>
	<4BB49B0C.1050901@enterprisedb.com>
Date: Thu, 1 Apr 2010 13:18:45 -0400
Received: by 10.239.131.199 with SMTP id 7mr71724hbo.175.1270142325946; Thu,
	01 Apr 2010 10:18:45 -0700 (PDT)
Message-ID: <j2t603c8f071004011018tbdcc5d17y1fe17b29ab08703c@mail.gmail.com>
Subject: Re: [DOCS] Streaming replication document improvements
From: Robert Haas <robertmhaas@gmail.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Fujii Masao <masao.fujii@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	pgsql-docs@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-0.838 tagged_above=-10 required=5
	tests=BAYES_00=-2.599, FS_REPLICA=1.041, SARE_SPEC_REPLICA=0.72
X-Spam-Level: 
X-Archive-Number: 201004/41
X-Sequence-Number: 160153

On Thu, Apr 1, 2010 at 9:09 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Fujii Masao wrote:
>> On Thu, Apr 1, 2010 at 11:00 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>>> You mean that we should change replication connection not to consume
>>>> superuser_reserved_connections slots in 9.0?
>>> Yes.
>
> I think it's good that walsenders can use the superuser reserved slots,
> that way a client that opens max_connections connections can't block out
> standby servers from connecting.
>
>> Preventing superuser connections from consuming superuser_reserved_connections
>> slots seems strange for me. So I'm leaning toward just removing superuser
>> privilege from replication connection again. Thought?
>
> That would be good, but I fear it's a bigger change than we should be
> doing at this point.
>
> How about we adjust the backends math a bit:
>
> Currently:
>
> ReservedBackends = superuser_reserved_connections
> MaxBackends = max_connections + autovacuum_max_workers + 1;
>
> Proposal:
>
> ReservedBackends = superuser_reserved_connections + max_wal_senders
> MaxBackends = max_connections + autovacuum_max_workers + max_wal_senders + 1
>
> So we implicitly reserve a slot and a superuser reserved slot for each
> walsender. Walsenders use the slots reserved for superusers, but if you
> set superuser_reserved_connections=3, there's still always at least
> three slots available for superuser to log in with psql, even if the
> maximum number of walsenders are connected.

That seems pretty reasonable to me.  I haven't checked how much code
impact there is.  I know Tom doesn't think we should change it at all,
but surely pre-beta is the time to fix nasty corner cases that were
added by recently committed patches?

...Robert