On Friday, November 16, 2012 4:09 AM Alvaro Herrera wrote: > Dimitri Fontaine wrote: > > Jan Wieck <janwi...@yahoo.com> writes: > > > Use this lmgr feature inside count_nondeletable_pages() of > vacuumlazy.c to > > > periodically check, if there is a conflicting lock request waiting. > If not, > > > keep going. If there is a waiter, truncate the relation to the point > checked > > > thus far, release the AccessExclusiveLock, then loop back to where > we > > > acquire this lock in the first place and continue > checking/truncating. > > > > I think that maybe we could just bail out after releasing the > > AccessExclusiveLock and trust autovacuum to get back to truncating > that > > relation later. > > That doesn't work, because the truncating code is not reached unless > vacuuming actually took place. So if you interrupt it, it will just not > get called again later. Maybe we could have autovacuum somehow invoke > that separately, but that would require that the fact that truncation > was aborted is kept track of somewhere.
Won't it have a chance to be handled next time when vacuum will trigger due to updates/deletes on some other pages. OTOH, may be next time again the same thing happens and it was not able to complete the truncate. So I think it's better to complete first time only, but may be using some heuristic time for wait and retry rather than with configuration variables. With Regards, Amit Kapila -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
