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 AANLkTinsGNxDm=ZRXfM0yNMjnrRUscmtGiURFC3ChMaT@mail.gmail.com
Whole thread Raw
In response to Re: Lock problem with autovacuum truncating heap  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Lock problem with autovacuum truncating heap
List pgsql-hackers
On Sun, Mar 27, 2011 at 2:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mar 26, 2011, at 4:16 PM, Jan Wieck <JanWieck@Yahoo.com> wrote:
>> That was what I meant. Go in steps of 16-64MB backwards and scan from there to the current end in forward direction
tofind a nondeletable block. In between these steps, release and reacquire the exclusive lock so that client
transactionscan get their work done. 
>
> Well, VACUUM uses a 16MB ring buffer, so anything that size or smaller should hit shared_buffers most of the time.
>
> I wonder though if this might defeat read-behind on operating systems that do have a working implementation.  With
ourcurrent approach each read will end at the point the previous read started, which might be an algorithm somebody is
usingto detect a backward scan. 

Good point. That means the last 16MB of buffers will be in
shared_buffers. Anything more than that will definitely not be,
because we wrote them out ourselves.

So we should truncate in 16MB chunks also.

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


pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: Needs Suggestion
Next
From: Pavel Stehule
Date:
Subject: Re: WIP: Allow SQL-language functions to reference parameters by parameter name