On Thu, Apr 1, 2010 at 5:39 AM, Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
