Re: vacuumdb parallel has a deadlock detected in 9.5.4

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: hubert depesz lubaczewski <depesz(at)depesz(dot)com>
Cc: huang <foggyglass(at)163(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: vacuumdb parallel has a deadlock detected in 9.5.4
Date: 2016-09-28 20:39:48
Message-ID: 20160928203947.GA360063@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

hubert depesz lubaczewski wrote:
> On Wed, Sep 28, 2016 at 09:46:22PM +0800, huang wrote:
> > Hi friends,
> >
> > There is a error deadlock detected in vacuumdb parallel .
> > but if I do not use parallel , it has not deadlock detected .
>
> man vacuumdb says about -j option:
>
> >> Note that using this mode together with the -f (FULL) option might cause
> >> deadlock failures if certain system catalogs are processed in parallel.
>
> so, while I understand it's not pretty, it's well documented.

Yeah. However I think this behavior is rather unhelpful. Maybe we
should try to fix it somehow, but I'm not sure how. We could say that
pg_catalog tables can only be processed one at a time, instead of trying
to paralelize them? For example: have vacuumdb fill two lists of
tables, one for pg_catalog and one for tables in other schemas. Each
worker chooses a table from the pg_catalog list first if it's not empty
and there's no other worker doing one of these, otherwise one from the
other table.

I think that'd fix it, while not destroying paralelizability too badly.

I'm not volunteering, though. Patches welcome.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message lr 2016-09-29 03:55:38 BUG #14344: string_agg(DISTINCT ..) crash
Previous Message hubert depesz lubaczewski 2016-09-28 17:29:37 Re: vacuumdb has a fatal after database rename