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