Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jiN5b-0004I9-BQ for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jun 2020 19:05:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jiN5a-0003JB-4q for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jun 2020 19:05:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jiN5Z-0003J3-Tg for pgsql-hackers@lists.postgresql.org; Mon, 08 Jun 2020 19:05:41 +0000 Received: from aart.rice.edu ([168.7.56.48]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jiN5U-0001qn-30 for pgsql-hackers@postgresql.org; Mon, 08 Jun 2020 19:05:40 +0000 Received: by aart.rice.edu (Postfix, from userid 18612) id F082E427F342; Mon, 8 Jun 2020 14:05:26 -0500 (CDT) Date: Mon, 8 Jun 2020 14:05:26 -0500 From: Kenneth Marshall To: Robert Haas Cc: Alvaro Herrera , Tomas Vondra , Magnus Hagander , Michael Paquier , Amit Kapila , David Fetter , PostgreSQL Development Subject: Re: Bump default wal_level to logical Message-ID: <20200608190526.GX22800@aart.rice.edu> References: <20200608133824.57lwoctf7gapnkmr@development> <20200608171619.GA11063@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Jun 08, 2020 at 02:58:03PM -0400, Robert Haas wrote: > On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera wrote: > > I think it's reasonable to push our default limits for slots, > > walsenders, max_bgworkers etc a lot higher than current value (say 10 -> > > 100). An unused slot wastes essentially no resources; an unused > > walsender is just one PGPROC entry. If we did that, and also allowed > > wal_level to be changed on the fly, we wouldn't need to restart in order > > to enable logical replication, so there would be little or no pressure > > to change the wal_level default. > > Wouldn't having a whole bunch of extra PGPROC entries have negative > implications for the performance of GetSnapshotData() and other things > that don't scale well at high connection counts? > +1 I think just having the defaults raised enough to allow even a couple DB replication slots would be advantageous and allow it to be used to address spur of the moment needs for systems that need to stay up. It does seem wasteful to by default support large numbers of slots and seems to be contrary to the project stance on initial limits. Regards, Ken