Parallel query behaving different with custom GUCs

Поиск
Список
Период
Сортировка
От Rushabh Lathia
Тема Parallel query behaving different with custom GUCs
Дата
Msg-id CAGPqQf2vvHzAWXEmGTYS=ezbenHKRaY=A=io9kbF=Spj7m0ebw@mail.gmail.com
обсуждение исходный текст
Ответы Re: Parallel query behaving different with custom GUCs  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Hayato Kuroda (Fujitsu)"
Дата:
Сообщение: RE: Synchronizing slots from primary to standby
Следующее
От: Xiang Gao
Дата:
Сообщение: RE: CRC32C Parallel Computation Optimization on ARM