Re: VACUUM FULL results in deadlock - Mailing list pgsql-bugs

From Manuel Rigger
Subject Re: VACUUM FULL results in deadlock
Date
Msg-id CA+u7OA7R=OZAf6_FxN7JXTU+3P7Kcwbno7Q4xcvRvQTGjSpY-Q@mail.gmail.com
Whole thread Raw
In response to Re: VACUUM FULL results in deadlock  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: VACUUM FULL results in deadlock  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-bugs
Thanks for your comment! I can also reproduce deadlocks for other
statements that operate on distinct databases, at least also for
ANALYZE. The documentation states that such statements operate on
their current databases. If this is not a bug, should maybe the
documentation be updated to mention this caveat?

Best,
Manuel

On Fri, Jul 5, 2019 at 3:17 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Jul 4, 2019 at 9:12 AM Manuel Rigger <rigger.manuel@gmail.com> wrote:
> > Did anyone try to verify this? I found a number of other race
> > conditions where VACUUM causes errors such as "ERROR: found unexpected
> > null value in index "i0", "invalid input syntax for type boolean", or
> > "missing chunk number 0 for toast value 13171 in pg_toast_2619".
> > Fixing this would help me to narrow down these issues.
>
> I don't know whether or not this is a bug, but my guess is that it
> isn't.  pg_database and several other system catalogs are shared
> relations, which means that they are shared by all databases. So, it's
> not too surprising that you could get some interaction between VACUUM
> FULL command in different databases.  Routine use of VACUUM FULL is
> something that should be avoided, so it doesn't seem like a huge
> problem to me that you can't run 32 of them at the same time.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company



pgsql-bugs by date:

Previous
From: Robert Haas
Date:
Subject: Re: BUG #15894: postgresql 9.5 will not install
Next
From: Robert Haas
Date:
Subject: Re: VACUUM FULL results in deadlock