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-26 16:12:24
Message-ID: AANLkTi=xu0XuqQ49u7=Q7KVe3EeZ1FqNuoDccp4Srcvc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

> At the same time I would
> change count_nondeletable_pages() so that it uses a forward scan direction
> (if that leads to a speedup).

Do we need that? Linux readahead works in both directions doesn't it?
Guess it wouldn't hurt too much.

BTW does it read the blocks at that point using a buffer strategy?

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-03-26 16:16:02 Re: race condition in sync rep
Previous Message Tom Lane 2011-03-26 16:04:56 Re: race condition in sync rep