| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
| Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Lock problem with autovacuum truncating heap |
| Date: | 2011-03-27 13:13:11 |
| Message-ID: | 0C6447D9-4C45-42F3-862B-A9C389DE0ECC@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2011-03-27 13:21:18 | Can I check if somebody is superuser in stored procedure? |
| Previous Message | Simon Riggs | 2011-03-27 11:57:52 | Re: Lock problem with autovacuum truncating heap |