On Wed, Nov 15, 2017 at 12:25 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Nov 14, 2017 at 11:00 AM, Tom Lane <t...@sss.pgh.pa.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
initplan-pushdown-with-dsa-1.patch
Description: Binary data
