On 2018-Oct-26, Tom Lane wrote: > After a quick look around, I think that making systable_begin/endscan > do this is a nonstarter; there are just too many call sites that would > be affected. Now, you could imagine specifying that indexes on system > catalogs (in practice, only btree) have to clean up at endscan time > but other index types don't, so that only operations that might be > scanning user indexes need to have suitable wrapping contexts. Not sure > there's a lot of benefit to that, though. How about modifying SysScanDescData to have a memory context member, which is created by systable_beginscan and destroyed by endscan? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services