Re: [sqlsmith] Parallel worker crash on seqscan
От | Robert Haas |
---|---|
Тема | Re: [sqlsmith] Parallel worker crash on seqscan |
Дата | |
Msg-id | CA+TgmoYQTTa8=7zu1er-2+sQS4jYa9JYVb=89UmvQUc6t4oReg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [sqlsmith] Parallel worker crash on seqscan (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [sqlsmith] Parallel worker crash on seqscan
|
Список | pgsql-hackers |
On Mon, Nov 21, 2016 at 12:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Nov 21, 2016 at 11:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> so what we've got is a case where a parameter computed by the FunctionScan >>> (in the master) would need to be passed into the parallel workers at >>> runtime. Do we have code for that at all? If so where is it? > >> No, that's not supposed to happen. > > OK, that makes this a planner failure: we should not have allowed this > query to become parallelized. > >> Maybe it's checking the quals but not recursing into the tlist? > > It seems like maybe searching for individual Params is the wrong thing. > Why are we allowing it to generate a parameterized Gather path at all? > Given the lack of any way to transmit runtime param values to the worker, > I can't see how that would ever work. Hmm, so you're thinking it could be the job of generate_gather_paths() to make sure we don't do that? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: