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: AANLkTinMLQxWNonDJC1FhZALRSdYMxNR_zbn6RwzAVyM@mail.gmail.com (view raw or flat)
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                   http://www.2ndQuadrant.com/
 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-2014 The PostgreSQL Global Development Group