On 9/17/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > > > Meanwhile I've started looking at the vacuum code, and it seems that v16 > has made that part of the patch significantly worse. VACUUM will fail > to count tuples that are removed by pruning, which seems like something > it should report somehow.
I understand. I did not give real weight to it because I thought we anyways remove tuples elsewhere during pruning. But I agree that the heap_page_prune_defrag in the VACUUM code path is doing so on behalf of vacuum and hence we should credit that to VACUUM. And you've introduced a race condition: as > I just mentioned, it's perfectly possible that the second call of > HeapTupleSatisfiesVacuum gets a different answer than what the prune > code saw, especially in lazy VACUUM (in VACUUM FULL it'd suggest that > someone released lock early ... but we do have to cope with that). Hmm.. you are right. Those extra notices I added are completely unnecessary and wrong. The comments you added seem to envision a more invasive patch that gets > rid of the second HeapTupleSatisfiesVacuum pass altogether, but I'm not > sure how practical that is, and am not real inclined to try to do it > right now anyway ... I agree. I just wanted to leave a hint there that such a possibility exists if someone really wants to optimize, now or later. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
