Re: VACUUM FULL results in deadlock

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: VACUUM FULL results in deadlock
Date: 2019-07-05 20:57:59
Message-ID: 27094.1562360279@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> I agree that you should not be running 32 full vacuums at once, much
> less in a loop, but if you do, they shouldn't result in weird corruption
> such as the ones reported.

BTW, looking at the OIDs in the original problem report, they are for
pg_authid and pg_shdepend, both of which are shared catalogs. It does not
seem terribly surprising to me that sets of operations that take out
exclusive locks on such catalogs are subject to deadlocks, especially not
when you consider that yet other sessions also have need to read those
catalogs. So I'm more or less in agreement with Robert that the deadlock
errors aren't very interesting. But I still concur with Alvaro that
those other error messages probably shouldn't be happening.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2019-07-05 22:14:31 Re: BUG #15896: pg_upgrade from 10-or-earlier: TRAP: FailedAssertion(»!(metad->btm_version >= 3)«
Previous Message PG Bug reporting form 2019-07-05 19:11:24 BUG #15898: pg_dump error not able to restore complete dump