On Fri, Apr 13, 2018 at 1:21 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On 13 April 2018 at 10:29, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
>> This is a Parallel Append with three processes working on three
>> subplans. It looks like one of the subplans got executed twice?
>
> Hi Thomas,
>
> Thanks for the report. If you're able to run the scripts in [1] and
> confirm you can reproduce the failure, if so, then revert the code
> back to 5c0675215 and see if you still get the additional loop.
>
> You'll need to update the expected results once back in 5c0675215 as
> the 6 subplans will no longer be removed.
>
> I've been unable to reproduce this so keen to get results from a
> machine that can.
I tried for some time with 1, 2 and 3 parallel copies of that shell
script you showed (after tweaking it to stick $$ into the filename
used for test.out so they didn't clobber each other). No dice,
couldn't make it fail.
So, as the option of last resort, I tried thinking about what's
actually going on here.
I think it might be working as designed! The participants are allowed
to run other subplans, because they're parallel sub-plans: it's just a
question of whether any backend manages to complete its subplan and
then go looking for another subplan to attack before it is marked as
complete. If that's true, then the loop number shown can't
technically be made stable, can it? Unless you make it so that the
scans were not allowed to be run by more than one worker.
--
Thomas Munro
http://www.enterprisedb.com