Re: vacuumdb -f and -j options (was Question / requests.)

On Mon, Oct 10, 2016 at 3:04 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Sun, Oct 9, 2016 at 10:59 PM, Francisco Olarte
> <folarte(at)peoplecall(dot)com> wrote:
>> For me -f & -j is not perfect, but better than not having it. It can
>> deadlock when given certain sets of catalog tables, either by making
>> it go for the full db or by a perverse set of -t options. But any DBA
>> needing them together should, IMO, have resources to write ( or have
>> someone else write for him ) a 20-liner wrapping and feeding them via
>> -t. After all, not every tool/option is for everyone, and everything
>> has it prerequisites.
> Okay, but I think that doesn't mean it should deadlock when used by
> somewhat naive user. I am not sure every user who wants to use -f and
> -j is smart enough to write a script as you are suggesting. I think
> if more people see your proposal as meaningful and want to leave
> current usage of -f and -j as it is, then probably, we should issue a
> warning indicating such a risk.

I agree. It should NOT deadlock, but sadly it does. And disallowing it
feels wrong. I'm all in for emitting a warning whenever it is used and
even disallowing it when no table list is given, but I was trying to
avoid the sugestion of just disallowing it always because it may
deadlock ( even with a table list it may, as nothing forbids you from
entering a locky set of tables ). And some people wrote what I
interpreted as 'throw it out if it is not perfect, put logic in to
make full paralell work partially in series so it does not deadlock or
forbid it all long' ( which is IMHO not easy, and I would dislike it,
if I order full paralell, vdb does it, if it deadlocks is because I
wanted it to, if someone wants that a new '--auto-serial-as-needed'
switch could be added ).

Francisco Olarte.