On Fri, Nov 30, 2012 at 9:46 PM, Heikki Linnakangas
> On 30.11.2012 21:02, Andres Freund wrote:
>> The subject says it all.
>> There are workloads where its detrimental, but in general having it
>> default to on improver experience tremendously because getting conflicts
>> because of vacuum is rather confusing.
>> In the workloads where it might not be a good idea (very long queries on
>> the standby, many dead tuples on the primary) you need to think very
>> carefuly about the strategy of avoiding conflicts anyway, and explicit
>> configuration is required as well.
>> Does anybody have an argument against changing the default value?
> -1. By default, I would expect a standby server to not have any meaningful
> impact on the performance of the master. With hot standby feedback, you can
> bloat the master very badly if you're not careful.
I'm with Heikki on the -1 on this. It's certainly unexpected to have
the slave affect the master by default - people will expect the master
to be independent.
Also, it doesn't IMHO actually *help*. The big thing that makes it
harder for people to set up replication that way is wal_level=minimal
by default, and in a smaller sense max_wal_senders (but
wal_level=minimal also has the interesting property that it's not
enough to change it to wal_level=hot_standby if you figure it out too
late - you have to turn off hot standby on the slave, start it, have
it catch up, shut it down, and reenable hot standby). And they
requires a *restart* of the master, which is a lot worse than a small
change to the config of the *slave*. So unless you're suggesting to
change the default of those two values as well, I'm not sure it really
helps that much...
> Think of someone setting up a test server, by setting it up as a standby
> from the master. Now, when someone holds a transaction open in the test
> server, you get bloat in the master. Or if you set up a standby for
> reporting purposes - a very common use case - you would not expect a long
> running ad-hoc query in the standby to bloat the master. That's precisely
> why you set up such a standby in the first place.
> You could of course still turn it off, but you would have to know about it
> in the first place. I think it's a reasonable assumption that a standby does
> *not* affect the master (aside from the bandwidth and disk space required to
> retain/ship the WAL). If you have to remember to explicitly set a GUC to get
> that behavior, that's a pretty big gotcha.
+1. Having your reporting query time out *shows you* the problem.
Having the master bloat for you won't show the problem until later -
when it's much bigger, and it's much more pain to recover from.
In response to
pgsql-hackers by date
|Next:||From: Magnus Hagander||Date: 2012-12-01 00:11:10|
|Subject: Re: Hot Standby Feedback should default to on in 9.3+|
|Previous:||From: Andres Freund||Date: 2012-12-01 00:00:37|
|Subject: Re: [PATCH] make -jN check fails / unset MAKEFLAGS in