Re: Why do we let autovacuum give up?

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Subject: Re: Why do we let autovacuum give up?
Date: 2014-01-23 21:41:31
Message-ID: 52E18C8B.1000105@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)kirkwood(at)catalyst(dot)net(dot)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.

Attachment Content-Type Size
temp.sql text/x-sql 14.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-01-23 21:56:47 Re: [bug fix] pg_ctl always uses the same event source
Previous Message Peter Geoghegan 2014-01-23 21:36:24 Re: Failure while inserting parent tuple to B-tree is not fun