On Wed, 2011-08-03 at 11:40 -0400, Tom Lane wrote: > The other problem is that once autovacuum has gotten the lock, it has > to keep it for long enough to re-scan the truncatable pages (to make > sure they're still empty). And it is set up so that any access to the > table will kick autovacuum off the lock. An access pattern like that > would very likely prevent it from ever truncating, if there are a lot > of pages that need to be truncated. (There's been some discussion of > modifying this behavior, but nothing's been done about it yet.) Ah! This looks like it is very much the issue. Since I've got around 150GB of data that should be truncatable and a select every ~2s. Just to confirm would postgres write: 2011-08-03 16:09:55 BST ERROR: canceling autovacuum task 2011-08-03 16:09:55 BST CONTEXT: automatic vacuum of table "traffic.public.logdata5queue" Under those circumstances? Cheers, -- Michael Graham <mgraham@xxxxxxxxx> -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
