On Tue, Jan 17, 2017 at 4:02 PM, Robert Haas <robertmh...@gmail.com> wrote: > Amit's chosen yet another possible place to insert the guard: teach > autovacuum that if a worker skips at least one table due to concurrent > autovacuum activity AND ends up vacuuming no tables, don't call > vac_update_datfrozenxid(). Since there is or was another worker > running, vac_update_datfrozenxid() either already has been called or > will be when that worker finishes. So that seems safe. If his patch > were changed to skip vac_update_datfrozenxid() in all cases where we > do nothing rather than only when we skip a table due to concurrent > activity, we'd reintroduce the dropped-database problem that was fixed > by 794e3e81a0e8068de2606015352c1254cb071a78.
After sleeping on this, I'm inclined to go with Amit's fix for now. It seems less likely to break anything in the back-branches than any other option I can think up. An updated version of that patch is attached. I changed the "if" statement to avoid having an empty "if" clause and a non-empty "else" clause, and I rewrote the comment based on my previous analysis. Barring objections, I'll commit and back-patch this version. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
prevent-useless-autovac-v2.patch
Description: invalid/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers