Message-ID: <a12e854c-e9e0-4a52-8bbf-53759f8e5fe0@iki.fi>
Date: Fri, 13 Mar 2026 15:14:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Add a check for interrupts in ginInsert
To: Vinod Sridharan <vsridh90@gmail.com>,
 pgsql-hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CAFMdLD6mQvAuStiOGvBJxAEfo6wdjZhj3+JveTLxOX8MVn4zmA@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CAFMdLD6mQvAuStiOGvBJxAEfo6wdjZhj3+JveTLxOX8MVn4zmA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/a12e854c-e9e0-4a52-8bbf-53759f8e5fe0%40iki.fi>
Precedence: bulk

On 12/03/2026 22:26, Vinod Sridharan wrote:
> Please find attached a small patch that adds the ability to check for
> interrupts during the insert into the GIN index. Currently, ginInsert
> can generate a large number of entries for a given input tuple from
> extractEntries. In the case of Json/Jsonb for instance, the standard
> opclasses may generate 1 term per path & value (which may be large).
> During index build, the build process does check for interrupts in
> between the inserts of each entry into the index (since there may be a
> large number of entries to insert). However, the same loop during
> insert was not checking for interrupts. This patch adds an interrupt
> check to allow for early termination if the overall request is
> abandoned. I believe this should be a safe point for checking for
> interrupts since we should not be in the middle of modifying the index
> tree in between entries.

Applied, thanks.

To test this, I created a large array:

create table largearray as select array_agg(g) from generate_series(1, 
10_000_000) g;

and table with a GIN index:

create table gintest (intarray int[]);
create index on gintest using gin (intarray);
-- to reach the ginHeapTupleInsert() function:
alter index gintest_intarray_idx set (fastupdate = off);

Without the patch, insertion into the index takes about 5 seconds on my 
laptop. A larger array with a more complicated extract function could 
take even longer. Without this patch, it's indeed uninterruptible. The 
fast-update path already had CHECK_FOR_INTERRUPTS() calls.

- Heikki