On Thu, 19 Feb 2026 at 19:30, Andres Freund <[email protected]> wrote:
> On 2026-02-19 19:06:04 +0200, Ants Aasma wrote:
> > After turning leader participation off the problem no longer
> > reproduced even after 10 iterations, turning it back on it reproduced
> > on the 4th iteration. Is there any reason why the hash table couldn't
> > have an unconditional iv that includes the plan node?
>
> You mean just use the numerical value of the pointer? I think that'd be pretty
> likely to be the same between parallel workers. And I think it's not great for
> benchmarking / debugging if every run ends up with a different IV.
>
> But we certainly should do something about the IV for the leader in these
> cases.
I was thinking more along the lines of hashing together the pointer
value and worker number. But something more deterministic would indeed
be better. How about this?
--- a/src/backend/executor/execGrouping.c
+++ b/src/backend/executor/execGrouping.c
@@ -201,3 +201,3 @@ BuildTupleHashTable(PlanState *parent,
MemoryContext oldcontext;
- uint32 hash_iv = 0;
+ uint32 hash_iv = parent->plan->plan_node_id;
I also figured out why this is not a more common issue.
The iv randomization is predicated on the aggregate node not having a
final function. Normally the partial hash aggregate will use
randomized iv and the finalize will use 0. But in this case because
it's implementing distinct, there is no finalize function on the upper
hash aggregate so on the leader the upper hash aggregate gets the same
iv as the one below gather.
Are there any other cases where a hash aggregate would be fed from
another hash aggregate using the same group key? Those could run into
the same problem.
Regards,
Ants Aasma
