Skip site navigation (1) Skip section navigation (2)

Re: Lock problem with autovacuum truncating heap

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Jan Wieck <JanWieck(at)yahoo(dot)com>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Lock problem with autovacuum truncating heap
Date: 2011-03-27 11:57:52
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Sat, Mar 26, 2011 at 8:05 PM, Jan Wieck <JanWieck(at)yahoo(dot)com> wrote:
> On 3/26/2011 12:12 PM, Simon Riggs wrote:
>> On Sat, Mar 26, 2011 at 2:30 PM, Jan Wieck<JanWieck(at)yahoo(dot)com>  wrote:
>>>  My current idea for a fix is to modify lazy_truncate_heap(). It does
>>> acquire
>>>  and release the exclusive lock, so it should be possible to do this in
>>>  smaller chunks, releasing and reacquiring the lock so that client
>>>  transactions can get their work done as well.
>> Agreed, presumably with vacuum delay in there as well?
> Not sure about that. My theory is that unless somebody needs access to that
> table, just have at it like it is now.
> The current implementation seems to assume that the blocks, checked for
> being empty, are still found in memory (vacuum just scanned them). And that
> seems to be correct most of the time, in which case adding vacuum delay only
> gives more time that the blocks get evicted and have to be read back in.

I think someone fairly clever already thought of that.
vacuum_cost_page_hit = 1 by default, so the cost of accessing pages
still in memory is 1/10th the cost of disk access. So we will only
perform the delay for each chunk if we had to read it from disk.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-03-27 13:13:11
Subject: Re: Lock problem with autovacuum truncating heap
Previous:From: Simon RiggsDate: 2011-03-27 11:46:42
Subject: Re: race condition in sync rep

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group