On 2015-02-03 13:51:25 +0100, Magnus Hagander wrote: > Those who want to optimize their WAL size can set it back to minimal, but > let's make the default the one that makes life *easy* for people.
Precisely. New users won't usually have tremendous stuff to load in the specific circumstances in which minimal makes a differences. And pretty much everyone uses base backups & replication outside of initial loading anyway. > The other option, which would be more complicated (I have a semi-finished > patch that I never got time to clean up) would be for pg_basebackup to be > able to dynamically raise the value of wal_level during it's run. It would > not help with the streaming standby part, but it would help with > pg_basebackup. That could be useful independent - for those who prefer > using wal_level=minimal and also pg_basebackup.. There's some ugly corner cases in making that happen. I'm sure we could do it, but I'm really not convinced it's worth the effort. > Previously there have been arguments against changing the default of > > wal_level because it'd mean the regression tests wouldn't exercise > > minimal anymore. That might be true, but then right now we just don't > > exercise the more complex levels. If we're really concerned we can just > > force a different value during the tests, just as we do for prepared > > xacts. > Seems we should focus our tests on the stuff that people actually use in > reality? :) And if we change the default, then even more people will use > that level. Agreed. It's not my argument ;) > But it would definitely be a good idea to have some buildfarm animals set > up to test each one. .oO(make it random in the buildfarm code) > > Additionally, more complex and further into the future, I wonder if we > > couldn't also get rid of wal_level = logical by automatically switching > > to it whenever logical slots are active. > If it can be safely done online, I definitely think that would be a good > goal to have. I think it could be at least made work on the primary. I don't really see how on a standby (which we don't support yet anyway). > If we could do the same for hot_standby if you had physical slots, > that might also be a good idea? I think it's slightly more complicated there. We'd have to delay slot creation till after a checkpoint and such, which doesn't seem that desirable. I think it's more interesting for logical anyway - there is some common workloads where it actually does imply some (not large, mind you) overhead. So we can't just change to it as a default. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers