From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Magnus Hagander <magnus@hagander.net>,
        Michael Paquier <michael@paquier.xyz>,
        Amit Kapila <amit.kapila16@gmail.com>,
 David Fetter <david@fetter.org>,
        PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: Bump default wal_level to logical
In-reply-to: <20200608171619.GA11063@alvherre.pgsql>
References: <20200608171619.GA11063@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Mon, 08 Jun 2020 13:16:19 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2021524.1591637270.1@sss.pgh.pa.us>
Date: Mon, 08 Jun 2020 13:27:50 -0400
Message-ID: <2021525.1591637270@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> 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.

Unused PGPROC entries will still consume semaphores, which is problematic
on at least some OSes.  It's not really clear to me why the default for
walsenders would need to be O(100) anyway.  The existing default of 10
already ought to be enough to cover approximately 99.999% of use cases.

If we can allow wal_level to be changed on the fly, I agree that would
help reduce the pressure to make the default setting more expensive.
I don't recall why it's PGC_POSTMASTER right now, but I suppose there
was a reason for that ...

			regards, tom lane