From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
cc: Bruno Wolff III <bruno@wolff.to>, pgsql-general@lists.postgresql.org,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Should pg 11 use a lot more memory building an spgist index?
In-reply-to: <b173372a-6c03-b5c3-08fc-64e8b4c3a817@lab.ntt.co.jp>
References: <20181024012314.GA27428@wolff.to> <19003.1540370028@sss.pgh.pa.us>
 <20181024083748.GA3296@wolff.to> <19088.1540372871@sss.pgh.pa.us>
 <20181025174306.GA3184@wolff.to> <24288.1540545369@sss.pgh.pa.us>
 <0e2b1baa-3d1c-7204-faa5-72c5d4a21a98@lab.ntt.co.jp>
 <25595.1540547983@sss.pgh.pa.us>
 <b173372a-6c03-b5c3-08fc-64e8b4c3a817@lab.ntt.co.jp>
Comments: In-reply-to Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
	message dated "Fri, 26 Oct 2018 19:08:44 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25755.1540549213.1@sss.pgh.pa.us>
Date: Fri, 26 Oct 2018 11:20:13 +0100
Message-ID: <25756.1540549213@sss.pgh.pa.us>
Precedence: bulk

Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> On 2018/10/26 18:59, 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.

> By "core code", I didn't mean systable_being/endscan, but rather
> check_exclusion_or_unique_constraint() or its core-side caller(s).

Well, we'd need to consider any call path leading to index_endscan.
One of those is systable_endscan and its multitude of callers.  It seems
unlikely that you could just switch context in systable_beginscan
without breaking many of the callers.

If we forbade leaks in system catalog index AMs, then the number of
places that would need work would be manageable (about 3, it looked
like).  But then it seems more like a wart than a real API improvement.

			regards, tom lane