| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
| 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:09:41 |
| Message-ID: | CA+TgmoYVbzb-4VWRsnF1g0oMQp0BtdtnwZ5HfJU2=ytZSaLKLQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Smith | 2014-01-23 21:11:20 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
| Previous Message | Robert Haas | 2014-01-23 21:08:32 | Re: [bug fix] pg_ctl always uses the same event source |