Re: [DOCS] Streaming replication document improvements - Mailing list pgsql-hackers

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 ----
>>         <para>
>>          Set the maximum number of concurrent connections from the standby servers
>>          (see <xref linkend="guc-max-wal-senders"> for details).
>> +        Since those connections are for superusers,
>> +        <xref linkend="guc-superuser-reserved-connections"> should be
>> +        set accordingly.
>>         </para>
>>        </listitem>
>>        <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 ****
>>   #recovery_target_timeline = '33'            # number or 'latest'
>>   #
>>   #---------------------------------------------------------------------------
>> ! # LOG-STREAMING REPLICATION PARAMETERS
>>   #---------------------------------------------------------------------------
>>   #
>>   # When standby_mode is enabled, the PostgreSQL server will work as
>> --- 88,94 ----
>>   #recovery_target_timeline = '33'            # number or 'latest'
>>   #
>>   #---------------------------------------------------------------------------
>> ! # STANDBY SERVER PARAMETERS
>>   #---------------------------------------------------------------------------
>>   #
>>   # 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="streaming-replication"> for details),
> +    WAL sender process is listed in the <command>ps</> display on the primary 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 replication 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,

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