Hi All,
We observed the behavioral difference when query(with custom GUC) using
the PARALLEL plan vs the Non-PARALLEL plan.
Consider the below test:
I understand the given testcase doesn't make much sense, but this is the
simplest
version of the test - to demonstrate the problem.
create table ptest2(id bigint, tenant_id bigint);
insert into ptest2 select g, mod(g,10) from generate_series(1, 1000000) g;
analyze ptest2;
-- Run the query by forcing the parallel plan.
postgres=> set max_parallel_workers_per_gather to 2;
SET
-- Error expected as custom GUC not set yet.
postgres=> select count(*) from ptest2 where current_setting('myapp.blah')
is null;
ERROR: unrecognized configuration parameter "myapp.blah"
-- Set the customer GUC and execute the query.
postgres=> set myapp.blah to 999;
SET
postgres=> select count(*) from ptest2 where current_setting('myapp.blah')
is null;
count
-------
0
(1 row)
*-- RESET the custom GUC and rerun the query.*postgres=> reset myapp.blah;
RESET
*-- Query should still run, but with forcing parallel plan, throwing an
error.*postgres=> select count(*) from ptest2 where
current_setting('myapp.blah') is null;
ERROR: unrecognized configuration parameter "myapp.blah"
CONTEXT: parallel worker
-- Disable the parallel plan and query just runs fine.
postgres=#set max_parallel_workers_per_gather to 0;
SET
postgres=#select count(*) from ptest2 where current_setting('myapp.blah')
is null;
count
-------
0
(1 row)
Looking at the code, while serializing GUC settings function
SerializeGUCState()
comments says that "We need only consider GUCs with source not
PGC_S_DEFAULT".
Because of this when custom GUC is SET, it's an entry there in the
"guc_nondef_list",
but when it's RESET, that is not more into "guc_nondef_list" and worker
is unable to access the custom GUC and ends up with the unrecognized
parameter.
We might need another placeholder for the custom GUCs. Currently, we are
maintaining 3 linked lists in guc.c - guc_nondef_list, guc_stack_list,
guc_report_list and to fix the above issue either we need a 4th list or do
changes in the existing list.
Thought/Comments?
Regards,
Rushabh Lathia
www.EnterpriseDB.com
