Re: Lock problem with autovacuum truncating heap - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Lock problem with autovacuum truncating heap
Date
Msg-id AANLkTi=xu0XuqQ49u7=Q7KVe3EeZ1FqNuoDccp4Srcvc@mail.gmail.com
Whole thread Raw
In response to Lock problem with autovacuum truncating heap  (Jan Wieck <JanWieck@Yahoo.com>)
Responses Re: Lock problem with autovacuum truncating heap
Re: Lock problem with autovacuum truncating heap
List pgsql-hackers
On Sat, Mar 26, 2011 at 2:30 PM, Jan Wieck <JanWieck@yahoo.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: race condition in sync rep
Next
From: Simon Riggs
Date:
Subject: Re: race condition in sync rep