On Mon, Oct 3, 2016 at 11:44 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas wrote: >> On Fri, Sep 30, 2016 at 11:20 AM, Francisco Olarte >> What messages are you seeing, exactly? "auto-deadlocking" isn't a thing. > https://www.postgresql.org/message-id/57EBC9AE.2060302%40163.com
Besides that even the docs for -j state "Note that using this mode together with the -f (FULL) option might cause deadlock failures if certain system catalogs are processed in parallel." So the only "safe" way to do -j -f seems to be using a table list. My proposed patch just makes it easy to build that by doing schema filtering. > I wonder if the real answer isn't just to disallow -f with parallel > vacuuming. It may be. I do not feel it is necessary, the docs are clear, this may be like disallowing knifes because you can cut yourself. IMO vacuumdb -f and -j are for people who know what they are doing, a warning may be nice anyway. Anyway, even if the combo is disallowed I feel schema filtering has its use. As an example, in some of my systems I have CDR tables partitioned by timestamp, either monthly or other period. As most of the data does not change I routinely coalesce many partitions and move them to a historic schema ( like I make a yearly partition and zap monthly ones, I still inherit from it ). This let me dump the historic schema when I change it and dump without the historic schema daily, greatly reducing dump times as the historic schema typically contains >90% of the data and it only changes when I have to do a back-fix to the data, which is very rare. Being able to do the same thing with vacuumdb could be useful. So, I'll just follow on executing my plan, but I'm prepared to abort it anytime if people feel it does not hold its weight. Most of the work is going to be learning how to submit a patch so it is reusable for me. Francisco Olarte. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
