Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dz0Wk-0002aT-Ut for pgsql-docs@arkaria.postgresql.org; Mon, 02 Oct 2017 13:12:55 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dz0Wk-0003KZ-Fx for pgsql-docs@arkaria.postgresql.org; Mon, 02 Oct 2017 13:12:54 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dz0Wj-0003H3-Ih for pgsql-docs@postgresql.org; Mon, 02 Oct 2017 13:12:53 +0000 Received: from smtprelay0166.b.hostedemail.com ([64.98.42.166] helo=smtprelay.b.hostedemail.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dz0Wc-0002tm-Bz for pgsql-docs@postgresql.org; Mon, 02 Oct 2017 13:12:52 +0000 Received: from filter.hostedemail.com (10.5.19.248.rfc1918.com [10.5.19.248]) by smtprelay04.b.hostedemail.com (Postfix) with ESMTP id 02B4F7B611; Mon, 2 Oct 2017 13:12:43 +0000 (UTC) X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267 X-Spam-Summary: 30,2,0,,d41d8cd98f00b204,alvherre@alvh.no-ip.org,:::,RULES_HIT:41:355:379:599:800:967:973:982:988:989:1028:1260:1277:1311:1312:1313:1314:1345:1359:1437:1515:1516:1518:1519:1534:1541:1593:1594:1595:1596:1711:1730:1747:1777:1792:2393:2525:2561:2564:2682:2685:2692:2693:2828:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4605:5007:6117:6119:6261:7514:7558:7903:9025:9121:10010:10400:10848:11026:11232:11658:11914:12043:12114:12438:12663:13069:13146:13161:13229:13230:13311:13357:13439:13894:13895:14181:14721:14764:21080:21627:30034:30054:30070,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:0,DNSBL:none,Custom_rules:0:1:0,LFtime:2,LUA_SUMMARY:none X-HE-Tag: slope37_8c2f246451961 X-Filterd-Recvd-Size: 2311 Received: from alvin.alvh.no-ip.org (unknown [109.131.231.247]) (Authenticated sender: alvherre@alvh.no-ip.org) by omf01.b.hostedemail.com (Postfix) with ESMTPA; Mon, 2 Oct 2017 13:12:43 +0000 (UTC) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id CECAF68C; Mon, 2 Oct 2017 15:12:41 +0200 (CEST) Date: Mon, 2 Oct 2017 15:12:41 +0200 From: Alvaro Herrera To: jonny.battiato@gmail.com Cc: pgsql-docs@postgresql.org Subject: Re: max_replication_slots in subscriber for subscription? Message-ID: <20171002131241.wi4zgyf2mhbchgbe@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170918170450.17363.89758@wrigleys.postgresql.org> User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org jonny.battiato@gmail.com wrote: > In this section: > https://www.postgresql.org/docs/10/static/logical-replication-config.html > > the following sentences make no sense in the way replication slots are > designed: > > "The subscriber also requires the max_replication_slots to be set. In this > case it should be set to at least the number of subscriptions that will be > added to the subscriber." > > I can understand if the subscriber would be used as a publisher as well, so > the second sentence could make more sense as follows: > > "In this case it should be set to at least the number of publications that > will be added to the subscriber." > > Could you please check? > And if I'm wrong, I would appreciate a little more clear explanation. Apparently, the reason for this (and correct me if I'm wrong) is that the maximum number of replication origins is determined from max_replication_slots, too. So the subscriber does not actually use any slots, but it needs some replication origins, which is why you need to increase the parameter. This seems a little silly to me, but patching the server to add the new variable is surely out of discussion for pg10. Should we change it in pg11? Also, do we want to add a footnote explaining this? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs