On Fri, Nov 30, 2012 at 6:49 PM, Heikki Linnakangas <[email protected]> wrote: >>> 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. > > > Hmm, it sounds like max_standby_streaming_delay=1d didn't work as intended > for some reason. It should've given the query one day to run before > canceling it. Unless the standby was running one day behind the master > already, but that seems unlikely. Any chance you could reproduce that?
I have a pre-production server with replication for these tests. I could create a fake stream of writes on it, disable feedback, and see what happens. -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
