Re: Hot Standby Feedback should default to on in 9.3+

On Fri, Nov 30, 2012 at 9:46 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 30.11.2012 21:02, Andres Freund wrote:
>>
>> Hi,
>>
>> 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.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/