From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Fix BUG #17335: Duplicate result rows in Gather node |
Date: | 2022-01-25 16:32:35 |
Message-ID: | 2258970.1643128355@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> writes:
> В Вт, 25/01/2022 в 21:20 +1300, David Rowley пишет:
>> The reason I didn't think it was worth adding a new test was that no
>> tests were added in the original commit. Existing tests did cover it,
> Existed tests didn't catched the issue. It is pitty fix is merged
> without test case it fixes.
I share David's skepticism about the value of a test case. The
failure mode that seems likely to me is some other code path making
the same mistake, which a predetermined test would not catch.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Pyhalov | 2022-01-25 16:37:32 | Re: Foreign join search stops on the first try |
Previous Message | tushar | 2022-01-25 16:22:12 | Re: refactoring basebackup.c |