Re: We need to log aborted autovacuums

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: We need to log aborted autovacuums
Date: 2011-01-16 18:08:36
Message-ID: 4D333424.1020104@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-01-16 18:16:14 Re: Include WAL in base backup
Previous Message Tom Lane 2011-01-16 18:08:03 Re: We need to log aborted autovacuums