Re: autovacuum process blocks without reporting a deadlock - Mailing list pgsql-general

From Tom Lane
Subject Re: autovacuum process blocks without reporting a deadlock
Date
Msg-id 21348.1196178730@sss.pgh.pa.us
Whole thread Raw
In response to Re: autovacuum process blocks without reporting a deadlock  ("Thomas Chille" <thomas@chille.de>)
Responses Re: autovacuum process blocks without reporting a deadlock  ("Thomas Chille" <thomas@chille.de>)
List pgsql-general
"Thomas Chille" <thomas@chille.de> writes:
> 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

I don't think the vacuum is the problem here.  The problem is process
9293, which for some reason is trying to get AccessExclusiveLock, and is
blocked behind autovac, and everything else is stacking up behind it.

You didn't happen to note what 9293 was doing did you?  It's living
fairly dangerously in any case by trying to acquire exclusive lock
when it already holds a bunch of other lower-level locks; that's a
recipe for deadlock if I ever saw one.

            regards, tom lane

pgsql-general by date:

Previous
From: "Thomas Chille"
Date:
Subject: Re: autovacuum process blocks without reporting a deadlock
Next
From: xeb@mail.ru
Date:
Subject: Re: ERROR: invalid restriction selectivity: 224359728.000000