| 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:16:56 |
| Message-ID: | 52E186C8.8050209@catalyst.net.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | MauMau | 2014-01-23 21:19:48 | Re: [bug fix] pg_ctl always uses the same event source |
| Previous Message | Tom Lane | 2014-01-23 21:15:50 | Re: Why do we let autovacuum give up? |