Received: from maia.hub.org (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 08EB86327B9;
	Wed, 31 Mar 2010 22:50:27 -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 21521-02; Thu,  1 Apr 2010 01:50:07 +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-gx0-f223.google.com (mail-gx0-f223.google.com
	[209.85.217.223])
	by mail.postgresql.org (Postfix) with ESMTP id 25846632FB4;
	Wed, 31 Mar 2010 22:50:16 -0300 (ADT)
Received: by gxk23 with SMTP id 23so566480gxk.15
	for <multiple recipients>; Wed, 31 Mar 2010 18:50:14 -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=FQD4FIC8DGz3BJCE0xZCoDJUn/+KvkVfQT44diHh4ac=;
	b=LRrPpggGIBuizoDpIPOcGHB+o9HAbukhITD/I1LiCNtJPkF3I6bSY6eC3M/3xpcXPg
	FFGWygoFl4xT3H3e6wU7G0t6Y83VjgpZJyY3lpr6UU7FU+fJginejnRgKDqVhJzOsgLT
	cxtY4T2fCS3W8mEwZm/JmevS1q1hSh58HKqx8=
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=ldcl/u5LhQtTWAetoeqSdQCIWuzuPMAFXEWpsoMJs3Df0pxkr4x5cTJ3eU3Jgo4KcN
	m533MWK86S1CG6XKAKVRI/8PfMHdW0TWF7wDHDt7e4UcneidTplohB+tA5fSVpRt4p8m
	ae5ngJMi9spFDq6VorfQ2t6q4whMGLxv3NGkA=
MIME-Version: 1.0
Received: by 10.100.253.9 with HTTP; Wed, 31 Mar 2010 18:50:13 -0700 (PDT)
In-Reply-To: <4BB3B2ED.5080606@enterprisedb.com>
References: <3f0b79eb1003300152g5327eb47w8f9aecae6002b215@mail.gmail.com>
	<4BB3B2ED.5080606@enterprisedb.com>
Date: Thu, 1 Apr 2010 10:50:13 +0900
Received: by 10.101.213.17 with SMTP id p17mr1110977anq.35.1270086614054;
 Wed,
	31 Mar 2010 18:50:14 -0700 (PDT)
Message-ID: <u2w3f0b79eb1003311850m50193801tb49b04966f5544d0@mail.gmail.com>
Subject: Re: Streaming replication document improvements
From: Fujii Masao <masao.fujii@gmail.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
	pgsql-docs@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=-1.202 tagged_above=-10 required=5 tests=AWL=-0.364,
	BAYES_00=-2.599, FS_REPLICA=1.041, SARE_SPEC_REPLICA=0.72
X-Spam-Level: 
X-Archive-Number: 201003/32
X-Sequence-Number: 5397

On Thu, Apr 1, 2010 at 5:39 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Fujii Masao wrote:
>> ***************
>> *** 829,834 **** if (!triggered)
>> --- 826,834 ----
>> =A0 =A0 =A0 =A0 <para>
>> =A0 =A0 =A0 =A0 =A0Set the maximum number of concurrent connections from=
 the standby servers
>> =A0 =A0 =A0 =A0 =A0(see <xref linkend=3D"guc-max-wal-senders"> for detai=
ls).
>> + =A0 =A0 =A0 =A0Since those connections are for superusers,
>> + =A0 =A0 =A0 =A0<xref linkend=3D"guc-superuser-reserved-connections"> s=
hould be
>> + =A0 =A0 =A0 =A0set accordingly.
>> =A0 =A0 =A0 =A0 </para>
>> =A0 =A0 =A0 =A0</listitem>
>> =A0 =A0 =A0 =A0<listitem>
>
> That's an interesting point, do streaming replication connections
> consume superuser_reserved_connections slots?

Yes. Since SR connection is superuser connection, setting
superuser_reserved_connections appropriately would be useful
to prevent non-superuser connections from blocking the connection
from the standby.

> How should
> superuser_reserved_connections be set?

Well.. setting the number of superuser connection required for
maintenance plus max_wal_senders seems to be reasonable.

>> *** a/src/backend/access/transam/recovery.conf.sample
>> --- b/src/backend/access/transam/recovery.conf.sample
>> ***************
>> *** 88,94 ****
>> =A0 #recovery_target_timeline =3D '33' =A0 =A0 =A0 =A0 =A0 =A0# number o=
r 'latest'
>> =A0 #
>> =A0 #-------------------------------------------------------------------=
--------
>> ! # LOG-STREAMING REPLICATION PARAMETERS
>> =A0 #-------------------------------------------------------------------=
--------
>> =A0 #
>> =A0 # When standby_mode is enabled, the PostgreSQL server will work as
>> --- 88,94 ----
>> =A0 #recovery_target_timeline =3D '33' =A0 =A0 =A0 =A0 =A0 =A0# number o=
r 'latest'
>> =A0 #
>> =A0 #-------------------------------------------------------------------=
--------
>> ! # STANDBY SERVER PARAMETERS
>> =A0 #-------------------------------------------------------------------=
--------
>> =A0 #
>> =A0 # When standby_mode is enabled, the PostgreSQL server will work as
>
> Hmm, that makes the HOT STANDBY notice after that section look weird:
>
>> #-----------------------------------------------------------------------=
----
>> # HOT STANDBY PARAMETERS
>> #-----------------------------------------------------------------------=
----
>> #
>> # Hot Standby related parameters are listed in postgresql.conf
>> #
>> #-----------------------------------------------------------------------=
----
>
> Do we need that notice? Maybe just move that sentence to the "STANDBY
> SERVER PARAMETERS" section.

I don't think that the notice is necessary. But I agree to the move.

> I just committed a patch to move around the high-availability sections a
> bit. That caused conflicts with this patch, so I picked the changes from
> the patch and applied them over the new layout, and I also did a lot of
> other editing. So, I committed most parts of this patch (except the
> above), with a lot of changes to fix the bit-rot, and also other editing
> to my liking. I hope I made it better not worse.

Thanks a lot!

doc/src/sgml/monitoring.sgml
> +    In streaming replication (see <xref linkend=3D"streaming-replication=
"> for details),
> +    WAL sender process is listed in the <command>ps</> display on the pr=
imary server.
> +    The form of its command line display is:
> + <screen>
> + postgres: wal sender process <replaceable>user</> <replaceable>host</> =
streaming <replaceable>location</>
> + </screen>
> +    The user and host items remain the same for the life of the replicat=
ion connection.
> +    The location indicates how far WAL sender process has sent the WAL.
> +    On the other hand, WAL receiver process is listed in the <command>ps=
</> display
> +    on the standby server. The form of its command line display is:
> + <screen>
> + postgres: wal receiver process streaming <replaceable>location</>
> + </screen>
> +    The location indicates how far WAL receiver has received the WAL.
> +   </para>
> +
> +   <para>

The original patch includes the above change for monitoring.sgml, but
it's been excluded from the commit. You think that it's not worth applying
the change?

Regards,

--=20
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center