Re: bug: Gather rescan keeps the first scan's tuple bound in workers

On 19/09/2026 05:05, shihao zhong wrote:
> Hi Jeff,
>
> Thanks for reporting this bug.
>
> I can reproduce this on master, and a 1000 row table is enough.
> The attached 0001 adds a tuples_needed argument to
> ExecParallelReinitialize() and stores it in the shared state, the same
> way ExecInitParallelPlan() does.  0002 is a regression test and is
> optional.
>
> For the back branches this changes the signature of an exported
> function.  I don't know of any extension that calls it, but if that is
> a concern, a new function could set the bound there instead.

I think you should merge patches 0001 and 0002. While you’re at it, you could
add a couple of words pointing out that the tuples_needed field of the
FixedParallelExecutorState structure needs to be updated on each rescan.

Also, for the back-patch you should add a wrapper for
ExecParallelReinitialize(), so that its existing signature stays intact in the
stable branches.

One more thing: the test covers only Gather Merge. It would be good to add the
same query without ORDER BY in the subquery, so that the plain Gather path is
exercised too.

--
regards, Andrei Lepikhov,
pgEdge