Simon Riggs wrote:
> I'm fairly confused by this thread.
>
That's becuase you think it has something to do with cancellation, which
it doesn't. The original report here noted a real problem but got the
theorized cause wrong. It turns out the code that acquires a lock when
autovacuum decides it is going to process something will wait forever
for that lock to be obtained. It cannot be the case that other locks on
the table are causing it to cancel, or as you say it would be visible in
the logs. Instead the AV worker will just queue up and wait for its
turn as long as it takes.
That does mean there's all sorts of ways that your AV workers can all
get stuck where they are waiting for a table, and there's no way to know
when that's happening either from the logs; you'll only see it in ps or
pg_stat_activity. Given that I think it's actually a mild denial of
service attack vector, this really needs an improvement.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books