Re: Skip all-visible pages during second HeapScan of CIC

Robert,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Fri, Mar 3, 2017 at 6:06 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > * Andres Freund (andres(at)anarazel(dot)de) wrote:
> >> On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote:
> >> > Since VM bits are only set during VACUUM which conflicts with CIC on the
> >> > relation lock, I don't see any risk of incorrectly skipping pages that the
> >> > second scan should have scanned.
> >>
> >> I think that's true currently, but it'd also prevent us from doing that
> >> in additional places. Which, in my opinion, we really should (and I
> >> believe that's realistically achievable). Thus I really don't want to
> >> base the correctness of CIC - a relatively infrequent operation - on the
> >> assumption that no VM bits can be set concurrenty due to the SUE lock.
> >
> > That sounds like we need a lock or similar mechanism to indicate that
> > CIC depends on the VM not being changed, rather than saying it shouldn't
> > depend on that because it might not always be true that the only other
> > operation (VACUUM) sets them and already acquires a conflicting lock.
>
> I don't really think that would be a useful approach. I think what
> Andres is thinking about -- or at least what comes to mind for me --
> is the possibility that heap_page_prune() might someday try to mark
> pages all-visible. Then it would become something that happens from
> time to time during foreground processing, rather than (as now)
> something that only happens from within a maintenance command.

Right, that's what I thought he was getting at and my general thinking
was that we would need a way to discover if a CIC is ongoing on the
relation and therefore heap_page_prune(), or anything else, would know
that it can't twiddle the bits in the VM due to the ongoing CIC.
Perhaps a lock isn't the right answer there, but it would have to be
some kind of cross-process communication that operates at a relation
level..

Just to be clear, I wasn't thinking that heap_page_prune() or a
foreground process would actually block on the lock, just that it would
try to acquire it if it decided that it could twiddle the VM and if it
wasn't able to immediately then it would just leave it alone and move
on. I'll admit that I'm not super familiar with the CIC or VM
internals, frankly, so I may be all wet with this entire line of
thinking, but figured I'd at least explain what the idea was.

Thanks!

Stephen