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