From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
Cc: | pgsql-hackers(at)postgresql(dot)org, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Subject: | Re: Why do we let autovacuum give up? |
Date: | 2014-01-23 21:15:50 |
Message-ID: | 10705.1390511750@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2014-01-23 21:16:56 | Re: Why do we let autovacuum give up? |
Previous Message | Pavel Stehule | 2014-01-23 21:14:44 | Re: Why do we let autovacuum give up? |