Re: Avoiding pin scan during btree vacuum - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Avoiding pin scan during btree vacuum
Date
Msg-id 11870.1450733810@sss.pgh.pa.us
Whole thread Raw
In response to Re: Avoiding pin scan during btree vacuum  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Avoiding pin scan during btree vacuum  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I think the new comment that talks about Toast Index should explain
> *why* we can skip the pinning in all cases except that one, instead of
> just saying we can do it.

I've not looked at that code in a long while, but my recollection is
that it's designed that way to protect non-MVCC catalog scans, which
are gone now ... except for SnapshotToast.  Maybe the right way to
approach this is to adjust HeapTupleSatisfiesToast (or maybe just
convince ourselves that no one could be dereferencing a stale toast
pointer in the first place?) and then redesign btree vacuuming without
the requirement to support non-MVCC scans, period.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Avoiding pin scan during btree vacuum
Next
From: Pavel Stehule
Date:
Subject: Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types