Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Check for interrupts during non-fast-update GIN insertion

  1. Add a check for interrupts in ginInsert

    Vinod Sridharan <vsridh90@gmail.com> — 2026-03-12T20:26:14Z

    Hello,
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.

Thanks and Regards,
Vinod Sridharan
[Microsoft]

  2. Re: Add a check for interrupts in ginInsert

    Heikki Linnakangas <hlinnaka@iki.fi> — 2026-03-13T13:14:12Z

    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