Re: Question / requests.

On Mon, Oct 3, 2016 at 11:44 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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.