Re: Vacuum as "easily obtained" locks

From: Michael Graham <mgraham(at)bloxx(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Vacuum as "easily obtained" locks
Date: 2011-08-03 15:45:41
Message-ID: 1312386341.24461.75.camel@brutus
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)bloxx(dot)com>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2011-08-03 15:52:02 Re: Vacuum as "easily obtained" locks
Previous Message Tom Lane 2011-08-03 15:40:39 Re: Vacuum as "easily obtained" locks