On Fri, Nov 30, 2012 at 6:20 PM, Kevin Grittner <kgri...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
