On Fri, Nov 30, 2012 at 9:46 PM, Heikki Linnakangas <hlinnakan...@vmware.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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers