From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jan Wieck <JanWieck(at)yahoo(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lock problem with autovacuum truncating heap |
Date: | 2011-03-27 17:24:54 |
Message-ID: | AANLkTinsGNxDm=ZRXfM0yNMjnrRUscmtGiURFC3ChMaT@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Mar 27, 2011 at 2:13 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mar 26, 2011, at 4:16 PM, Jan Wieck <JanWieck(at)Yahoo(dot)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 to find a nondeletable block. In between these steps, release and reacquire the exclusive lock so that client transactions can 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 our current approach each read will end at the point the previous read started, which might be an algorithm somebody is using to 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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2011-03-27 17:30:43 | Re: WIP: Allow SQL-language functions to reference parameters by parameter name |
Previous Message | Gurjeet Singh | 2011-03-27 17:20:36 | Re: Needs Suggestion |