Re: Fix BUG #17335: Duplicate result rows in Gather node
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Yura Sokolov <y.sokolov@postgrespro.ru>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2022-02-04T00:07:42Z
Lists: pgsql-hackers
Attachments
- do_some_plan_validation_during_create_plan.patch (application/octet-stream) patch
On Wed, 26 Jan 2022 at 05:32, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Therefore, what I think could be useful is some very-late-stage > assertion check (probably in createplan.c) verifying that the > child of a Gather is parallel-aware. Or maybe the condition > needs to be more general than that, but anyway the idea is for > the back end of the planner to verify that we didn't build a > silly plan. I had a go at writing something along these lines, but I've ended up with something I really don't like very much. I ended up having to write a recursive path traversal function. It's generic and it can be given a callback function to do whatever we like with the Path. The problem is, that this seems like quite a bit of code to maintain just for plan validation in Assert builds. Currently, the patch validates 3 rules: 1) Ensure a parallel_aware path has only parallel_aware or parallel_safe subpaths. 2) Ensure Gather is either single_copy or contains at least one parallel_aware subnode. 3) Ensure GatherMerge contains at least one parallel_aware subnode. I had to relax rule #1 a little as a Parallel Append can run subnodes that are only parallel_safe and not parallel_aware. The problem with relaxing this rule is that it does not catch the case that this bug report was about. I could maybe tweak that so there's a special case for Append to allow parallel aware or safe and ensure all other nodes have only parallel_safe subnodes. I just don't really like that special case as it's likely to get broken/forgotten over time when we add new nodes. I'm unsure if just being able to enforce rules #2 and #3 make this worthwhile. Happy to listen to other people's opinions and ideas on this. Without those, I'm unlikely to try to push this any further. David
Commits
-
Consider parallel awareness when removing single-child Appends
- 2ccd8fb29d74 12.10 landed
- f8807e7742e5 13.6 landed
- 357ff66153b4 14.2 landed
- f9a74c1498d2 15.0 landed
-
Suppress Append and MergeAppend plan nodes that have a single child.
- 8edd0e79460b 12.0 cited