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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Alexander Lakhin <exclusion@gmail.com>

Cc: Pavel Borisov <pashkin.elfe@gmail.com>, pgsql-bugs@lists.postgresql.org

Date: 2024-09-13T19:45:11Z

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

I wrote:
> Looking at hashbuild, the effective sort_threshold depends on
> NBuffers, so maybe if you have that set to a high enough value
> it fails to go into the sort path?  If I use
> SET maintenance_work_mem = '128MB';
> instead of the suggested 1GB, I don't see the problem.

Oh, false alarm: that test in hashbuild takes basically the
min of maintenance_work_mem and NBuffers, so that with
default NBuffers of 128MB, there's no difference here between
those two settings.

The reason I see a difference in behavior seems to be that
with maintenance_work_mem = 1GB, the tuple sorting step
completes faster, allowing control to reach _h_indexbuild
before the 10sec timeout I was testing with.  With the
smaller maintenance_work_mem setting, we're still sorting
when it times out --- and there are CHECK_FOR_INTERRUPTS
calls in the sort code.

			regards, tom lane