Re: HOT synced with HEAD

On 9/17/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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