Re: Hot Standby Feedback should default to on in 9.3+
От | Magnus Hagander |
---|---|
Тема | Re: Hot Standby Feedback should default to on in 9.3+ |
Дата | |
Msg-id | CABUevEwwY96ZWte_FM8m-0bpHZsNGbqp7Thqi=Mgn0L6JBbX=w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hot Standby Feedback should default to on in 9.3+ (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: Hot Standby Feedback should default to on in 9.3+
("Albe Laurenz" <laurenz.albe@wien.gv.at>)
|
Список | pgsql-hackers |
On Fri, Nov 30, 2012 at 9:46 PM, Heikki Linnakangas <hlinnakangas@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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Andres FreundДата:
Сообщение: Re: [PATCH] make -jN check fails / unset MAKEFLAGS in pg_regress.c
Следующее
От: Magnus HaganderДата:
Сообщение: Re: Hot Standby Feedback should default to on in 9.3+