"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> I'm glad we got away with a single "marked" array. I was afraid we would
> need to consult the unused/redirected/dead arrays separately.
Yeah, I was worried about that too. The fundamental reason why it's
okay seems to be that redirects can only be the heads of HOT chains.
Therefore, a newly marked tuple cannot be a member of any chain we'll
need to scan later, no matter whether it is marked as newly redirected,
dead, or unused. And so we can just ignore marked tuples in all cases.
I set up the code to mark the redirection target too, but that is just a
minor optimization AFAICS --- if we reach the redirection target later
in the outer scan loop, we'd decide not to process it anyway.
> Do you have a plan for the invalidation problem? I think we could just
> not remove the redirection line pointers in catalog tables.
Still thinking about it, but I agree that I'd rather make a small
modification to VACUUM FULL than try to redesign cache invalidation.
The trick with not removing redirect pointers would be to ensure we
don't remove the redirection target. While the redirection target was
presumably not DEAD when heap_page_prune looked at it, it seems possible
that it is DEAD by the time vacuum.c looks. Another risk factor is
trying to move the redirection target down to a lower page.
regards, tom lane
