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

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company