Re: Problem about postponing gathering partial paths for topmost scan/join rel - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Problem about postponing gathering partial paths for topmost scan/join rel
Date
Msg-id 516633.1659201304@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problem about postponing gathering partial paths for topmost scan/join rel  (Antonin Houska <ah@cybertec.at>)
List pgsql-hackers
Antonin Houska <ah@cybertec.at> writes:
> I'm going to set the CF entry to "ready for committer'".

I pushed this with some editorialization:

* Grepping found another caller of generate_useful_gather_paths
with the exact same bug, in geqo_eval.c.  (A wise man once said
that the most powerful bug-finding heuristic he knew was "where
else did we make this same mistake?")

* I thought it best to make set_rel_pathlist() use an identically-
worded test for the equivalent purpose for baserels.  It's not
actively broken, but examining bms_membership seems confusingly
complicated, and I doubt it's faster than bms_equal either.

* I omitted the test case because I didn't think it would buy us
anything.  It failed to detect the GEQO variant of the bug, and
it would fail to detect the most likely future way of breaking
this, which is that I forget to change these instances of
all_baserels next time I rebase [1].

            regards, tom lane

[1] https://commitfest.postgresql.org/39/3755/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Next
From: Tom Lane
Date:
Subject: Re: Add test of pg_prewarm extenion