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
