Re: Why do we let autovacuum give up?
От | Mark Kirkwood |
---|---|
Тема | Re: Why do we let autovacuum give up? |
Дата | |
Msg-id | 52E18C8B.1000105@catalyst.net.nz обсуждение исходный текст |
Ответ на | 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 |
On 24/01/14 10:16, Mark Kirkwood wrote: > On 24/01/14 10:09, Robert Haas wrote: >> On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood >> <mark.kirkwood@catalyst.net.nz> wrote: >>> 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. regards, >>>> tom lane >>> 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. >> But... how does that result on a vacuum-incompatible lock request >> against pg_attribute? >> >> I see that it'll insert lots of rows into pg_attribute, and maybe >> later delete them, but none of that blocks vacuum. >> > > That was my thought too - if I see it happening again here (was a year > or so ago that I saw some serious pg_attribute bloat) I'll dig deeper. > > Actually not much digging required. Running the attached script via pgbench (8 sessions) against a default configured postgres 8.4 sees pg_attribute get to 1G after about 15 minutes.
Вложения
В списке pgsql-hackers по дате отправления: