Re: Why do we let autovacuum give up?
От | Tom Lane |
---|---|
Тема | Re: Why do we let autovacuum give up? |
Дата | |
Msg-id | 10705.1390511750@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Why do we let autovacuum give up? (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>) |
Ответы |
Re: Why do we let autovacuum give up?
|
Список | pgsql-hackers |
Mark Kirkwood <mark.kirkwood@catalyst.net.nz> writes: > On 24/01/14 09:49, Tom Lane wrote: >> 2. What have you got that is requesting exclusive lock on >> pg_attribute? That seems like a pretty unfriendly behavior in itself. > I've seen this sort of problem where every db session was busily > creating temporary tables. I never got to the find *why* they needed to > make so many, but it seemed like a bad idea. That shouldn't result in any table-level exclusive locks on system catalogs, though. [ thinks... ] It's possible that what you saw is not the kick-out-autovacuum-entirely behavior, but the behavior added in commit bbb6e559c, whereby vacuum (auto or regular) will skip over pages that it can't immediately get an exclusive buffer lock on. On a heavily used table, we might skip the same page repeatedly, so that dead tuples don't get cleaned for a long time. To add insult to injury, despite having done that, vacuum would reset the pgstats dead-tuple count to zero, thus postponing the next autovacuum. I think commit 115f41412 may have improved the situation, but I'd want to see some testing of this theory before I'd propose back-patching it. regards, tom lane
В списке pgsql-hackers по дате отправления: