Re: Can parallel vacuum commands lead to a lock in Postgres 10.2

From: PT <wmoran(at)potentialtech(dot)com>
To: Meikel Bisping <info(at)mbisping(dot)de>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Can parallel vacuum commands lead to a lock in Postgres 10.2
Date: 2018-02-15 21:47:57
Message-ID: 20180215164757.a71bd17db345814d1f3db25e@potentialtech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 15 Feb 2018 17:40:48 +0100
Meikel Bisping <info(at)mbisping(dot)de> wrote:

> Hello,
>
> we have lots of scripts which issue individual vacuum commands to tables
> like "vacuum full gxstage_bs" but also general "vaccum full" commands.
> Until now these scripts run sequentially and there are no problems.
> Now the idea is to run some scripts in parallel, my question is if
> parallel vacuum commands can lead to a lock in 10.2?
> Unfortunately it isn't easy to change the scripts and rely on
> auto-vacuum since they are installed on lots of customers' hosts and
> installing updates is very complex.

They lock already. Running in parallel isn't going to lead to any
new locks.

I don't think that's what you're asking, though. I'm guessing that
what you're asking is are you going to experience deadlocks or other
types of unresolvable lock scenarios.

By design, no. In my experience, no.

In the real world ... it's always possible that you will uncover some
edge-case bug that leads to an unresolvable deadlock. I would rate that
as pretty unlikely, though. Locking is a pretty fundamental part of
Postgres that gets a lot of testing.

--
Bill Moran

In response to

Browse pgsql-general by date

  From Date Subject
Next Message PT 2018-02-15 21:55:17 Re: query's performance
Previous Message hmidi slim 2018-02-15 21:43:59 query's performance