> Hello, > I recently looked at what it would take to make a running autovacuum > pick-up a change to either cost_delay or cost_limit. Users frequently > will have a conservative value set, and then wish to change it when > autovacuum initiates a freeze on a relation. Most users end up > finding out they are in ‘to prevent wraparound’ after it has happened, > this means that if they want the vacuum to take advantage of more I/O, > they need to stop and then restart the currently running vacuum (after > reloading the GUCs).
Hello, I think this has been overlooked, right? I can't find a relevant commit, but maybe I just didn't look hard enough. I have a feeling that this is something that we should address. If you still have the cycles, please consider posting an updated patch and creating a commitfest entry.
Thanks! Yeah, I should be able to get this together next week.
Thanks
-- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Someone said that it is at least an order of magnitude more work to do production software than a prototype. I think he is wrong by at least an order of magnitude." (Brian Kernighan)
