Re: [sqlsmith] Crash in apply_projection_to_path

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andreas Seltenreich <seltenreich(at)gmx(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [sqlsmith] Crash in apply_projection_to_path
Date: 2016-04-30 16:32:39
Message-ID: 20535.1462033959@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Fri, Apr 29, 2016 at 7:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> make_join_rel is certainly not far enough down the call stack to solve
>> this problem. It can, and typically will, be invoked multiple times
>> for the same target join relation.
>>
>> One possible answer is to do it in standard_join_search, just before
>> the set_cheapest call for each join relation.

> Yes, that makes sense to me.

Done that way.

> Yet, another idea could be to create a copy of partial path before passing
> it to create_gather_path()?

That's just a kluge, and I'm not exactly convinced it'd solve the problem
anyway, unless you wanted to recursively copy the entire infrastructure
of the partial path. What's needed is to set rules for how we build paths
up in an orderly fashion. Such rules already existed for regular paths
(see the comments I added in c45bf5751), and now they exist for parallel
paths as well.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andre Mikulec 2016-04-30 16:39:54 Re: SPI_exec ERROR in pl/r of R 3.2.4 on PostgreSQL on Windows 7
Previous Message Bruce Momjian 2016-04-30 16:30:18 Re: New 9.6 external sort guidance around temp_tablespaces and maintenance_work_mem