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
