Re: Fix BUG #17335: Duplicate result rows in Gather node - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Fix BUG #17335: Duplicate result rows in Gather node
Date
Msg-id CA+TgmoZG2Lfg=rk4-Vc4_shHLbOjtCEYy1tCLjSzcUx7Kpk_6Q@mail.gmail.com
Whole thread Raw
In response to Re: Fix BUG #17335: Duplicate result rows in Gather node  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Fix BUG #17335: Duplicate result rows in Gather node
List pgsql-hackers
On Thu, Feb 3, 2022 at 7:08 PM David Rowley <dgrowleyml@gmail.com> wrote:
> Currently, the patch validates 3 rules:
>
> 1) Ensure a parallel_aware path has only parallel_aware or
> parallel_safe subpaths.

I think that every path that is parallel_aware must also be
parallel_safe. So checking for either parallel_aware or parallel_safe
should be equivalent to just checking parallel_safe, unless I am
confused.

I think the actual rule is: every path under a Gather or GatherMerge
must be parallel-safe.

I don't think there's any real rule about what has to be under
parallel-aware paths -- except that it would have to be all
parallel-safe stuff, because the whole thing is under a Gather
(Merge). There may seem to be such a rule, but I suspect it's just an
accident of whatever code we have now rather than anything intrinsic.

> 2) Ensure Gather is either single_copy or contains at least one
> parallel_aware subnode.

I agree that this one is a rule which we could check.

> 3) Ensure GatherMerge contains at least one parallel_aware subnode.

This one, too.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: do only critical work during single-user vacuum?
Next
From: Alexander Korotkov
Date:
Subject: Re: [PATCH] reduce page overlap of GiST indexes built using sorted method