| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: hung backends stuck in spinlock heavy endless loop |
| Date: | 2015-01-14 15:08:04 |
| Message-ID: | CAHyXU0yTPe7QzAqRVWfcw=9agkZn6uO3GFCBm63VuAw3CTTXxg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 14, 2015 at 9:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Wed, Jan 14, 2015 at 8:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> What are the autovac processes doing (according to pg_stat_activity)?
>
>> pid,running,waiting,query
>> 7105,00:28:40.789221,f,autovacuum: VACUUM ANALYZE pg_catalog.pg_class
>
> Hah, I suspected as much. Is that the one that's stuck in
> LockBufferForCleanup, or the other one that's got a similar
> backtrace to all the user processes?
Yes, it is pg_class is coming from LockBufferForCleanup (). As you
can see above, it has a shorter runtime. So it was killed off once
about a half hour ago which did not free up the logjam. However, AV
spawned it again and now it does not respond to cancel.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-01-14 15:11:47 | Re: hung backends stuck in spinlock heavy endless loop |
| Previous Message | Tom Lane | 2015-01-14 15:05:01 | Re: hung backends stuck in spinlock heavy endless loop |