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? How should superuser_reserved_connections be set? > *** 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 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers