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