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