Skip site navigation (1) Skip section navigation (2)

Re: Streaming replication document improvements

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-docs(at)postgresql(dot)org
Subject: Re: Streaming replication document improvements
Date: 2010-04-01 01:50:13
Message-ID: u2w3f0b79eb1003311850m50193801tb49b04966f5544d0@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-docspgsql-hackers
On Thu, Apr 1, 2010 at 5:39 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

pgsql-docs by date

Next:From: Robert HaasDate: 2010-04-01 01:52:48
Subject: Re: [DOCS] Streaming replication document improvements
Previous:From: Bruce MomjianDate: 2010-04-01 00:31:32
Subject: Re: confusing archive_command example

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-04-01 01:52:48
Subject: Re: [DOCS] Streaming replication document improvements
Previous:From: Bruce MomjianDate: 2010-04-01 01:43:37
Subject: Re: sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group