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.
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/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
