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:

Reply via email to