Re: Nasty bug in heap_page_prune

On Thu, Mar 13, 2008 at 10:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> But we could push them out earlier, ie,
> before making the actual page changes in heap_page_prune. This seems
> safe since an unnecessary invalidation notice cannot break anything,
> at worst it causes useless work.
>

If I understand correctly, that would let us call CacheInvalidateHeapTuple()
outside a critical section. Seems like a good idea to me.

>
> I'm inclined to set this up as having heap_page_prune first call
> a function named something like "BeginNontransactionalInvalidation",
> then do its CacheInvalidateHeapTuple calls, then call
> "EndNontransactionalInvalidation". In the initial implementation
> the first would just assert that the inval queue is empty, and the
> second would push out the queue. If we ever need to generalize
> things then the code structure would be there to build a phony
> subtransaction.
>

I wonder if we can have a separate list of non-transaction events in
InvalidationListHeader and broadcast those events irrespective of
transaction commit or abort. But we may still need the
"BeginNontransactionalInvalidation" and "EndNontransactionalInvalidation"
markers to push these events to the non-transactional list.

> Obviously this is a bit of a hack, but there's hardly anything about
> VACUUM FULL that's not a bit of a hack ...
>

True :-) And I would personally prefer any hack than playing with left
over redirected line pointers in VACUUM FULL.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com