Re: Lock problem with autovacuum truncating heap
От
Robert Haas
Тема
Re: Lock problem with autovacuum truncating heap
Дата
Msg-id
0C6447D9-4C45-42F3-862B-A9C389DE0ECC@gmail.com
Ответ на
Re: Lock problem with autovacuum truncating heap (Jan Wieck)
Список
Дерево обсуждения
Lock problem with autovacuum truncating heap Jan Wieck <JanWieck@Yahoo.com>
Re: Lock problem with autovacuum truncating heap Simon Riggs <simon@2ndQuadrant.com>
Re: Lock problem with autovacuum truncating heap Jan Wieck <JanWieck@Yahoo.com>
Re: Lock problem with autovacuum truncating heap Simon Riggs <simon@2ndQuadrant.com>
Re: Lock problem with autovacuum truncating heap Itagaki Takahiro <itagaki.takahiro@gmail.com>
Re: Lock problem with autovacuum truncating heap Robert Haas <robertmhaas@gmail.com>
Re: Lock problem with autovacuum truncating heap Jan Wieck <JanWieck@Yahoo.com>
Re: Lock problem with autovacuum truncating heap Robert Haas <robertmhaas@gmail.com>
Re: Lock problem with autovacuum truncating heap Simon Riggs <simon@2ndQuadrant.com>
Re: Lock problem with autovacuum truncating heap Jan Wieck <JanWieck@Yahoo.com>
Re: Lock problem with autovacuum truncating heap Robert Haas <robertmhaas@gmail.com>
Re: Lock problem with autovacuum truncating heap Tom Lane <tgl@sss.pgh.pa.us>
Re: Lock problem with autovacuum truncating heap Jan Wieck <JanWieck@Yahoo.com>
Re: Lock problem with autovacuum truncating heap Robert Haas <robertmhaas@gmail.com>
Re: Lock problem with autovacuum truncating heap Jan Wieck <JanWieck@Yahoo.com>
Re: Lock problem with autovacuum truncating heap Greg Stark <gsstark@mit.edu>
Re: Lock problem with autovacuum truncating heap Tom Lane <tgl@sss.pgh.pa.us>
Re: Lock problem with autovacuum truncating heap Jan Wieck <JanWieck@Yahoo.com>
Re: Lock problem with autovacuum truncating heap Jan Wieck <JanWieck@Yahoo.com>
Re: Lock problem with autovacuum truncating heap Jim Nasby <jim@nasby.net>
On Mar 26, 2011, at 4:16 PM, Jan Wieck 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
В списке pgsql-hackers по дате отправления
От: Pavel Stehule
Дата: