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
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 |