Re: Hot Standby Feedback should default to on in 9.3+
От | Claudio Freire |
---|---|
Тема | Re: Hot Standby Feedback should default to on in 9.3+ |
Дата | |
Msg-id | CAGTBQpb=yTM2BiByzzrP+1+hRtHM7jPeSKSZY7WYAmiAYFWcRg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hot Standby Feedback should default to on in 9.3+ ("Kevin Grittner" <kgrittn@mail.com>) |
Ответы |
Re: Hot Standby Feedback should default to on in 9.3+
|
Список | pgsql-hackers |
On Fri, Nov 30, 2012 at 6:20 PM, Kevin Grittner <kgrittn@mail.com> wrote: > Claudio Freire wrote: > >>> With what setting of max_standby_streaming_delay? I would rather >>> default that to -1 than default hot_standby_feedback on. That >>> way what you do on the standby only affects the standby. >> >> 1d > > Was there actually a transaction hanging open for an entire day on > the standby? Was it a query which actually ran that long, or an > ill-behaved user or piece of software? No, and if there was, I wouldn't care for it to be cancelled. Queries were being cancelled way before that timeout was reached, probably something to do with max_keep_segments on the master side being unable to keep up for that long. > I have most certainly managed databases where holding up vacuuming > on the source would cripple performance to the point that users > would have demanded that any other process causing it must be > immediately canceled. And canceling it wouldn't be enough at that > point -- the bloat would still need to be fixed before they could > work efficiently. I wouldn't mind occasional cancels, but these were recurring. When a query ran long enough, there was no way for it to finish, no matter how many times you tried. The master never stops being busy, that's probably a factor.
В списке pgsql-hackers по дате отправления: