2018年12月29日(土) 1:44 Tom Lane <t...@sss.pgh.pa.us>: > > Kohei KaiGai <kai...@heterodb.com> writes: > > I've investigated a crash report of PG-Strom for a few days, then I doubt > > add_partial_path() can unexpectedly release dominated old partial path > > but still referenced by other Gather node, and it leads unexpected system > > crash. > > Hm. This seems comparable to the special case in plain add_path, where it > doesn't attempt to free IndexPaths because of the risk that they're still > referenced. So maybe we should just drop the pfree here. > > However, first I'd like to know why this situation is arising in the first > place. To have the situation you're describing, we'd have to have > attempted to make some Gather paths before we have all the partial paths > for the relation they're for. Why is that a good thing to do? It seems > like such Gathers are necessarily being made with incomplete information, > and we'd be better off to fix things so that none are made till later. > Because of the hook location, Gather-node shall be constructed with built-in and foreign partial scan node first, then extension gets a chance to add its custom paths (partial and full). At the set_rel_pathlist(), set_rel_pathlist_hook() is invoked next to the generate_gather_paths(). Even if extension adds some partial paths later, the first generate_gather_paths() has to generate Gather node based on incomplete information. If we could ensure Gather node shall be made after all the partial nodes are added, it may be a solution for the problem.
Of course, relocation of the hook may have a side-effect. Anyone may expect the pathlist contains all the path-node including Gather node, for editorialization of the pathlist. Thanks, -- HeteroDB, Inc / The PG-Strom Project KaiGai Kohei <kai...@heterodb.com>