Received: from maia.hub.org (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 3A7866356FB;
	Tue, 20 Apr 2010 11:45:24 -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 23378-04-6; Tue, 20 Apr 2010 14:45:04 +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-iw0-f187.google.com (mail-iw0-f187.google.com
	[209.85.223.187])
	by mail.postgresql.org (Postfix) with ESMTP id 81207635DA0;
	Tue, 20 Apr 2010 11:01:49 -0300 (ADT)
Received: by iwn17 with SMTP id 17so689365iwn.19
	for <multiple recipients>; Tue, 20 Apr 2010 07:01:48 -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
	:content-transfer-encoding;
	bh=xgF7SiGATHQVqWoBSN/dE7nnkbO8aFqGtTJiWnIWIYE=;
	b=WWaOhUzP0w51O+nBntuVCgOOlv8A5nZT8kotavpGZX/Vaej0xTnQtueEmcuQuyjAby
	8ZWPB8EW1m0ilM1h3JtwlH1EKvz37xDsqBD6pK77cOPyp3f/fe4WLKiCeC/Faug8TJQl
	bCSpmIFfOLfKEs6ZM4byvqx3BFHoETzBkGzYc=
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:content-transfer-encoding;
	b=RqwszBsqUBBDvNVXlG5tR6Tmid+zXM63jWVp/UYmIPtQXdRXIXvUJS9/5MyGjQigSx
	wE/Ho3FLUru3qGRJVTFMoa+DfzqTcihRRvrtv59t28AZlJvU/NArxjCn3i9njByL/tuU
	xC7sRica38By3gUHvOau4K01Ycqb+6kE2TgRk=
MIME-Version: 1.0
Received: by 10.231.38.194 with HTTP; Tue, 20 Apr 2010 07:01:48 -0700 (PDT)
In-Reply-To: <h2w3f0b79eb1004200647nc0aa56d8ibb4be9f2f00731f5@mail.gmail.com>
References: <3f0b79eb1003300152g5327eb47w8f9aecae6002b215@mail.gmail.com>
	<19262.1270142946@sss.pgh.pa.us>
	<4BB4952D0200002500030333@gw.wicourts.gov>
	<4BB4DBEF.3010301@agliodbs.com>
	<o2m603c8f071004011058neb6e0ea1r1f5caccbb7c50402@mail.gmail.com>
	<k2i3f0b79eb1004012306xdfa88c1cudd77b61368c997ea@mail.gmail.com>
	<w2z603c8f071004191904yefcaba2fy1abc2020174a35c5@mail.gmail.com>
	<s2u3f0b79eb1004200247q2f1c35f0pc7bf4af306f3514c@mail.gmail.com>
	<j2r603c8f071004200352s5e175371z8bd42b9c18807fe@mail.gmail.com>
	<h2w3f0b79eb1004200647nc0aa56d8ibb4be9f2f00731f5@mail.gmail.com>
Date: Tue, 20 Apr 2010 10:01:48 -0400
Received: by 10.231.190.149 with SMTP id di21mr2417527ibb.41.1271772108618;
	Tue, 20 Apr 2010 07:01:48 -0700 (PDT)
Message-ID: <h2g603c8f071004200701jff98aca6sfd063608572e463@mail.gmail.com>
Subject: Re: [HACKERS] Streaming replication document improvements
From: Robert Haas <robertmhaas@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Josh Berkus <josh@agliodbs.com>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	pgsql-docs@postgresql.org,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.074 tagged_above=-10 required=5 tests=AWL=-2.345,
	BAYES_00=-1.9, FS_REPLICA=3.599, SARE_SPEC_REPLICA=0.72
X-Spam-Level: 
X-Archive-Number: 201004/68
X-Sequence-Number: 5467

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 =3D superuser_reserved_connections + max_wal_senders
>> MaxBackends =3D max_connections + autovacuum_max_workers + max_wal_sende=
rs + 1

This seemed sensible to me when Heikki first described it, but now it
seems overly complex.

> 2. My proposal
> =A0 =A0Remove 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
> =A0 =A0Treat 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