Re: BUG #18314: PARALLEL UNSAFE function does not prevent parallel index build

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18314: PARALLEL UNSAFE function does not prevent parallel index build
Date: 2024-02-07 11:54:33
Message-ID: CAHewXNkSYVYktt0KW8RtfNMDYi4Stn7OJtuTqeo+c3He1xoFXQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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(at)gmail(dot)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(at)postgresql(dot)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(at)gmail(dot)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/

Attachment Content-Type Size
0001-Fix-parallel-index-build-failed.patch application/octet-stream 12.7 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Ivan Kalafatić 2024-02-07 14:08:27 Re: BUG #18315: Segmentation fault on connection (repmgr, psql)
Previous Message just madhu 2024-02-07 11:42:06 Re: pgjdbc is not working with PKCS8 certificates with password