Re: BUG #18616: Long-running hash index build can not be interrupted

Pavel Borisov <pashkin.elfe@gmail.com>

From: Pavel Borisov <pashkin.elfe@gmail.com>

To: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org

Date: 2024-09-13T14:51:30Z

Lists: pgsql-bugs

Commits

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

Allow _h_indexbuild() to be interrupted.
- fae55f0bb385 18.0 landed
- 418c6a2c72d2 17.0 landed
- e0857898b87b 15.9 landed
- d23109f4bd65 16.5 landed
- b49013f2e86a 14.14 landed
- b27215dbb42b 13.17 landed
- 813ade54806c 12.21 landed

Attachments

0001-Check-for-interrupts-during-hash-index-builds.patch (application/octet-stream) patch 0001

Hi, Alexander!

On Fri, 13 Sept 2024 at 18:02, PG Bug reporting form <noreply@postgresql.org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference:      18616
> Logged by:          Alexander Lakhin
> Email address:      exclusion@gmail.com
> PostgreSQL version: 17rc1
> Operating system:   Ubuntu 22.04
> Description:
>
> The following script:
> CREATE TABLE t(i int);
> INSERT INTO t SELECT 1 FROM generate_series(1, 10000000);
>
> SET maintenance_work_mem = '1GB';
>
> SET statement_timeout = '90s';
> CREATE INDEX hi ON t USING hash (i);
>
> reaches a state, when the backend can not be interrupted.
>
> gdb shows that the code execution loops inside:
> #0  _h_indexbuild (...) at hashsort.c:151
> #1  0x0000557f3671cbf3 in hashbuild (...)
>     at hash.c:183
> ...
> with tups_done increasing slowly (given the total number of tuples).
>
> Reproduced on all supported versions.
>
I was unable to reproduce it on my machine with these settings. Tried
statement timeouts 30-120s. Index build appears to be in interruptible
phase on my system.
But could you check in your environment with the following patch?

Kind regards,
Pavel Borisov
Supabase