Re: BUG #18314: PARALLEL UNSAFE function does not prevent parallel index build
Tender Wang <tndrwang@gmail.com>
From: Tender Wang <tndrwang@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2024-02-07T11:54:33Z
Lists: pgsql-bugs
Attachments
- 0001-Fix-parallel-index-build-failed.patch (application/octet-stream) patch 0001
In pg document, I found this: Also, a block containing an EXCEPTION clause effectively forms a subtransaction that can be rolled back without affecting the outer transaction. So it will report error for this case even though we replace PARALLEL UNSAFE with PARALLEL SAFE. I think if PARALLEL UNSAFE is specified by users, PG internal should not choose to build index parallel, even if the function is too simply that can be transform to Const node. Attached patch will fix Alexander reported issue. I choose pass the raw index expression to is_parallel_safe(). The comments of RelationGetIndexExpressions() doesn't say it will return optimized expression. So I add a bool argument to RelationGetIndexExpressions(). I don't decide to write a new function like RelationGetIndexRawExpression. I think the RelationGetIndexExpressions() is enough after adding a bool argument to indicate whether caller needing a raw index expression. But if users specify PARALLEL SAFE, like I said before, it also reports error. But I think it is another thing. Maybe it is reasonable? Tender Wang <tndrwang@gmail.com> 于2024年1月29日周一 22:36写道: > Thanks for reporting this issue. > > I debug the process of creating index, and in plan_create_index_workers() > func, which use the planner to > decide if use parallel building index. > > But the index expression passed to is_parallel_safe() has already > simplified by RelationGetIndexExpressions() func. > In this case, FunExpr node will be simplified to Const node. So the check > in is_parallel_safe() will return true. > > The goal of plan_create_index_workers() is to decide whether it's safe to > build index parallelly. I think we just check the raw index > expression no need to simplify the index expression. > > > PG Bug reporting form <noreply@postgresql.org> 于2024年1月29日周一 19:02写道: > >> The following bug has been logged on the website: >> >> Bug reference: 18314 >> Logged by: Alexander Lakhin >> Email address: exclusion@gmail.com >> PostgreSQL version: 16.1 >> Operating system: Ubuntu 22.04 >> Description: >> >> When planner chooses to perform parallel index build, it doesn't >> check whether functions used in an index expression or predicate are >> parallel-safe. For example: >> CREATE FUNCTION f() RETURNS int IMMUTABLE PARALLEL UNSAFE >> AS $$ >> BEGIN >> RETURN 0; >> EXCEPTION WHEN OTHERS THEN >> RETURN 1; >> END$$ LANGUAGE plpgsql; >> >> CREATE TABLE t(i int); >> INSERT INTO t SELECT g FROM generate_series(1, 300000) g; >> CREATE INDEX ON t((i + f())); >> >> results in: >> ERROR: cannot start subtransactions during a parallel operation >> CONTEXT: PL/pgSQL function f() line 2 during statement block entry >> parallel worker >> >> Although with 200000 records, the index created with no error. >> >> Reproduced on REL_12_STABLE .. master. >> >> > > -- > Tender Wang > OpenPie: https://en.openpie.com/ > -- Tender Wang OpenPie: https://en.openpie.com/
Commits
-
Revert "Fix parallel-safety check of expressions and predicate for index builds"
- 69e8f9dadb01 12.19 landed
- 70a31629aede 13.15 landed
- 49b971298a9b 14.12 landed
- e82b64a92cf5 15.7 landed
- c46817ee512a 16.3 landed
- 099ca50bd41c 17.0 landed
-
Fix parallel-safety check of expressions and predicate for index builds
- c0e0174c216b 12.19 landed
- b60d71c202cd 13.15 landed
- 56a8ab2fc6f7 14.12 landed
- 50b5913a87c9 15.7 landed
- 4ec8f7708b6b 16.3 landed
- eae7be600be7 17.0 landed
-
Ensure we preprocess expressions before checking their volatility.
- 743ddafc7124 17.0 cited