On Fri, Mar 3, 2017 at 6:06 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Andres Freund (and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
