Re: VACUUM FULL results in deadlock
От | Manuel Rigger |
---|---|
Тема | Re: VACUUM FULL results in deadlock |
Дата | |
Msg-id | CA+u7OA7R=OZAf6_FxN7JXTU+3P7Kcwbno7Q4xcvRvQTGjSpY-Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: VACUUM FULL results in deadlock (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: VACUUM FULL results in deadlock
|
Список | 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 по дате отправления: