On 21 December 2015 at 21:36, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvhe...@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.
Advertising
Yes, that's the principle in use here. Which means we can optimize away the
scan on a Hot Standby in all cases except for Toast Index vacuums.
> 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.
>
We could, but its likely to be a much more complex patch.
I'm happy with this being a simple patch now, not least because I would
like to backpatch this to 9.4 where catalog scans became MVCC.
A backpatch is warranted because it is a severe performance issue with
replication and we can fix that before 9.5 hits the streets.
I'll be doing some more testing and checking, so not in a rush.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services