On Fri, Apr 29, 2016 at 8:07 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Apr 28, 2016 at 10:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Andreas Seltenreich <seltenre...@gmx.de> writes: > >> the following query against the regression database crashes master as of > >> 23b09e15. > > > >> select 1 from depth0 inner join depth1 on (depth0.c = depth1.c) > >> where depth0.c @@ depth1.c limit 1; > > > > What's going on here is that add_partial_path is recycling a now-dominated > > partial path without regard for the fact that there's already a GatherPath > > pointing at that old partial path. Later use of the GatherPath tries to > > make use of its now-dangling subpath pointer. > > > > I'd be inclined to think that it's silly to build GatherPaths in advance > > of having finalized the list of partial paths for a rel. > > Uh ... yeah, that shouldn't be happening. I obviously screwed something up. >
What's happening here is that to form joinrel, we need to call add_paths_to_joinrel() with both outer and inner relation twice, once with rel1 as outer relation and rel1 as inner relation and vice versa. So now the second call to add_paths_to_joinrel() can replace a partial path which is being referenced by GatherPath generated in first call. I think we should generate gather paths for join rel after both the calls to add_paths_to_joinrel() aka in make_join_rel(). Attached patch on above lines fixes the problem for me. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
fix_parallel_join_path_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
