Re: BUG #11444: autovacuum stuck for 5 days and waits on a lock
От | Alexey Klyukin |
---|---|
Тема | Re: BUG #11444: autovacuum stuck for 5 days and waits on a lock |
Дата | |
Msg-id | CAAS3ty+unNJ0vSqR1CLLdy7BrOWxkvRwJqpHg=pbLdY++gHN+A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #11444: autovacuum stuck for 5 days and waits on a lock (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-bugs |
On Wed, Sep 17, 2014 at 6:12 PM, Andres Freund <andres@2ndquadrant.com> wrote: >> There are also UPDATE statements constantly running on this table, in the >> overlapping manner, so at a single moment there is at least one update >> running on it. We are investigating why is it done this way, but can it be a >> reason behind this strange vacuum behavior? > > Which quite possibly is caused by this. > > > I've recently commented on -hackers that this is a very hard to debug > behaviour and should be made more visible, but IIRC we didn't come to a > conclusion... Thank you, we've verified that the index in question is scanned as a result of the sub-SELECT statement producing the data for the resulting UPDATE. We are looking into simplifying it to avoid the long-running scans, hopefully, we'll pull this before the transaction wraparound will come for this cluster :-) -- Regards, Alexey Klyukin
В списке pgsql-bugs по дате отправления: