Re: [HACKERS] parallelize queries containing initplans

On Wed, Nov 15, 2017 at 12:25 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Nov 14, 2017 at 11:00 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yeah, I'm sure it is. I have a vague recollection that there might be
>> existing regression test cases exercising such things, though I won't
>> swear to that. The "orderstest" bit in subselect.sql looks like it
>> might be meant to do that...
>

I agree that such cases can cause a problem with fixed memory.

> Here's an updated patch that attempts to work around this problem using DSA.
>

There were a couple of problems with your changes:
1.
BufferUsage *buffer_usage; /* points to bufusage area in DSM */
+ dsa_handle param_exec; /* serialized PARAM_EXEC parameters */
@@ -35,12 +36,13 @@ typedef struct ParallelExecutorInfo
} ParallelExecutorInfo;

This should be dsa_pointer, otherwise, the value returned by
SerializeParamExecParams will get truncated.

2. In ExecParallelReinitialize(), we need to evaluate the params
before serializing them.

3. I think we should free the dsa pointer at the end of the gather.

Attached patch fixes the mentioned problems.

> It could use a test case that actually tickles the new logic in
> ExecParallelReinitialize ... this is mostly just to show the concept.
>

Thanks, it was quite helpful.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com