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.