On 2015-08-18 21:47:51 -0400, Peter Eisentraut wrote: > On 8/18/15 1:46 PM, Andres Freund wrote: > > I don't think not requiring restarts is sufficient, having to twiddle a > > bunch of parameters manually still is a lot more effort than people see > > as necessary. > > I agree that we want both. But requiring a restart is a hard stop, > whereas making configuration easier is a soft feature.
I don't think it makes that much of a difference for people new to postgres. > > To deal with streaming replication, we automatically create slots for > > replicas, but, by default, *without* having them reserve WAL. The slot > > name would be determined in some automatic fashion (uuid or something) > > and stored in a new file in the data directory. That allows us to > > increase the internal wal_level to hot_standby/archive whenever a > > replica has connected (and thus a physical slot exists), and to logical > > whenever a logical slot exists. > > That seems kind of weird. So every time a replication client connects, > we create a new replication slot? Won't they accumulate? No, that's not what I was thinking of. The name of the slot would be stored somewhere in the data directory, and then be reused henceforth. > Do we need the replication slot, or could we just trigger this on the > existence of a replication client? I don't think that can work, because a replication connection obviously can go away temporarily. If we'd then fall back to wal_level minimal the standby would be cut off. > Also note that this scheme and any similar one requires merging the > archive and hot_standby levels, which was the core of your original > proposal [1] It doesn't really, we could continue to keep them separate. I'm proposing to maintain wal_level automatically, so it'd not be configurable anymore, so it'd not matter much, as long as we're not less efficient. > , which was then objected to, which subsequently lead to > Robert's proposal to make wal_level SIGHUP, which lead to my message, > which lead to your message, which is similar to your initial one. > Somehow we have to find a way break out of this circle. ;-) My reading of the objections was that it was primarily about increasing the amount of WAL in the default configuration, and this proposal wouldn't anymore. An out-of-the-box configuration wouldn't emit more WAL than today, until it's been used with streaming rep. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers