| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Thomas Chille <thomas(at)chille(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: autovacuum process blocks without reporting a deadlock |
| Date: | 2007-11-27 14:14:16 |
| Message-ID: | 20071127141416.GA7332@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Thomas Chille wrote:
> I think this are the relevant pg_locks entries:
>
> relation 75685778 75686189
> 9017862 25467 AccessShareLock f
> relation 75685778 75686189
> 9009323 9317 ShareUpdateExclusiveLock
> t
> relation 75685778 75686189
> 9009312 9293 AccessShareLock t
> relation 75685778 75686189
> 9009312 9293 RowExclusiveLock t
> relation 75685778 75686189
> 9009312 9293 AccessExclusiveLock f
> relation 75685778 75686189
> 9012978 28370 AccessShareLock f
>
> 75686189 is the table hst_timerecording. for me it looks like the
> autovacuum is not releasing the blocking ShareUpdateExclusiveLock?
What are the column headings? I find this difficult to read.
Please post the whole of pg_locks. I may be missing something but I
think we're missing part of the picture here. Autovacuum does not seem
to be locking on anything.
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
One man's impedance mismatch is another man's layer of abstraction.
(Lincoln Yeoh)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Selena Deckelmann | 2007-11-27 14:23:15 | Re: POLL: Women-sized t-shirts for PostgreSQL |
| Previous Message | Thomas Chille | 2007-11-27 13:59:48 | Re: autovacuum process blocks without reporting a deadlock |