From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Skip all-visible pages during second HeapScan of CIC |
Date: | 2017-03-03 23:06:51 |
Message-ID: | 20170303230651.GW9812@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres,
* 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.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-03-03 23:12:04 | Re: Skip all-visible pages during second HeapScan of CIC |
Previous Message | Peter Geoghegan | 2017-03-03 23:03:37 | Re: Skip all-visible pages during second HeapScan of CIC |