Incorrect function markings

[MMeent]

Steps to reproduce

Check the generated SQL, code, and migrations

Expected result

• Functions that depend on non-GUC backend-local state for their output are not marked as PARALLEL SAFE

Actual result

Functions that depend on non-GUC backend-local state are marked as PARALLEL SAFE:

• session() accesses JWT, a thread-local variable that is initialized ~once based off of GUCs, but updated with set_jwt_cache, which is called from session() when JWT has not been initialized yet. So, the following command sequence invalidates the PARALLEL SAFE part (example query):

  SET pg_session_jwt.jwt = "foo";
  SELECT session();
  SET pg_session_jwt.jwt = "bar";
  SELECT session() FROM my_parallel_query;
  -- output produced by the main process will have output based off of `jwt = foo`, while parallel processes produce output from `jwt = bar`, as those are only initialized after starting the parallel query.

• user_id() uses the output of session(), and thus has the same issues.

This can be solved by passing a GucStringAssignHook to DefineCustomStringVariable (or its pgrx equivalent).

[conradludgate]

We were informed that parallel workers are shutdown after every query. Is that then not the case?

[conradludgate]

This can be solved by passing a GucStringAssignHook to DefineCustomStringVariable (or its pgrx equivalent).

Looks like there is no pgrx equivalent at present. For now I will add a manual slower check for if the GUC has changed.

[MMeent]

We were informed that parallel workers are shutdown after every query. Is that then not the case?

no, that is correct. But data produced in a parallel worker may be different if their local state is constructed differently from others; e.g. pg_backend_pid() would output differently across backends, and is thus marked parallel restricted - the query may be parallel, but the function can only be executed in the primary process, never in a parallel portion of the plan.

[davidgomes]

@MMeent can we close this now?